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1.  Tliis  military  handbook  is  approved  for  u2C  by  all  departments  and  agencies  of  the  Department 
of  Defense  (DoDj. 

2.  Beneficial  comments  (recommendations,  additions,  deletions)  and  any  pertinent  data  that  may 
be  of  use  in  improving  this  document  should  be  addressed  to  Commander,  U.  S,  Army 
Communicaiions-Eiectronics  Command  (CECOM),  ATTN:  AMSEL-RD-SE-R-CRM,  Fort 
Monmouth,  NJ  07703  -5000. 

3  As  Department  of  Defense  (DoD)  systems  increase  their  reliance  on  computers,  software 
complexity  increases  and  its  criticality  grows.  Computer  software  is  a  necessary  element  in  DoD 
systems.  The  results  oi Desert  Storm  demonstrated  the  force  multiplier  that  software  provides. 
Modem  management  practices  use  work  breakdown  structures  to  help  provide  visibility  into  and 
manage  risk  involved  with  software  developments.  .An  organization  that  instruments  its  process, 
infrastructure,  and  quali'y  will  have  better  management  control  over  resources  and  associated 
risks.  The  handbook  shows  how  to  achieve  thai  objective  through  existing  contractor  cost/ 
schedule  control  systems  by  properly  struciming  the  contract  WBS,  statement  of  work  WBS,  and 
reporting  requirements.  The  goals  are  to  control  softv/are  cost  by  improving  software 
management  and  measurement  techniques  and  to  provide  reliable  performance  reports  to  the 
Government  at  practical  summary  levels. 

4.  The  Ada  Joint  Program  Office  determined  that  use  of  WBS  for  identifying  and  collecting 
software  costs  would  be  an  effective  management  tool.  As  pan  of  a  U.  S.  Army  Materiel 

U  U  liM  f  'C)  oiudy  on  the  defense  software  life  cycle  acquisition  process,  the  LI  S.  Army 
Materiel  Command  (AMC)  Software  Task  Force  Report,  28  February  1989,  recommended  that  an 
effective  cost  reporting  and  ttacking  process  be  established  for  controlling  and  managing  software 
development  and  support  costs.  This  study  initiated  the  development  of  a  WBS  for  software 
elements.  Additionally,  DoD  emphasis  was  placed  on  more  visible  software  costs  including 
modification  of  MIL-STD-881,  Work  Breakdown  Structures  for  Defense  Materiel  Items, 
reflecting  software  visibility  requirements. 

5.  in  March  1990,  the  Softw'are  Executive  Officials  (SEC)  established  a  Software  WBS  Working 
Group.  The  charter,  to  review  and  develop  a  DcD  handbook  designed  to  formalize  Software 
WBSs  and  recommend  changes  to  MIL-STD-881.  This  handbook,  titled  Work  Breakdown 
Structure  Elements  for  Software,  improves  the  situation  by  providing  tailorable  guidance  through 
the  use  of  the  detailed  software  elements  and  the  WBS  common  framework  procedures  outlined 
in  MIL-STD-881B.  This  handbook  assists  the  practitioner  with  the  implemenlation  of  Public  Law 
102-172,  Sec  8044,  that  provided,  effective  July  1, 1992,  all  new  Department  of  Defense 
procurements  shall  separately  identify  software  costs  in  the  work  breakdown  structure  defined  by 
MIL-STD-881  in  those  instances  where  software  is  considered  a  major  category  of  cost. 

6.  This  handbook  was  developed  by  the  Software  WBS  Working  Group  in  coordination  with  the 
Joint  Logistic  Commanders  Joint  Policy  Coordinating  Group  for  Computer  Resource 
Management  and  the  AMC  Software  Task  Force,  and  with  the  assistance  of  the  U.  S.  Army 
CECOM  Software  Engineering  Directorate  and  the  Air  Force  Cost  Analysis  Agency.  Active 
participation  by  the  National  Security  Agency,  the  Defense  Information  System  Agency,  the 
Services,  the  Office  of  the  Secretary  of  Defense,  government  software  development  contractors, 
and  industry  through  the  National  Security  Industrial  Association  and  the  Electronics  Industries 
Association  brought  this  lugli  priority  initiative  to  a  successful  conclusion. 
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1.  SCOPE 

1.1  Purpose.  MIL-MDBK-r/J  (hereafter  referred  to  as  the  handbeok)  provides  a  framework 
for  identifying  and  extending  Work  Breakdown  Structure  elements  related  to  software  when 
implementing  DoD  acquisition  policy  and  MIL-STD-881B.  This  framework  provides  guidance  to 
Industry  and  Government  to  better  monitor,  track,  analyze,  and  estimate  the  cost  of  developing 
and  supporting  defense  system  software.  The  handbook  shows  how  an  acqui-sition  can  be  planned 
and  how  contractor/developer  software  management  information  can  be  tailored  to  the  specific 
requirements  of  the  acquisition. 

1.2  Application. 

1.2.1  Use.  This  handbook  used  in  conjunction  with  MIL-STD-881B  provides  guidance  for 
further  identifying  software  co.st3  in  the  WBS  in  those  instances  where  software  is  considered  to 
be  a  major  category  of  cost.  This  handbook  is  a  guide  for  both  contractors  and  DoD  components 
(government  activities)  to  further  define  elements  below  the  software  element  requirement 
established  in  MIL-STD-881B  (Work  Breakdown  Structure  for  Defense  Materiel  Iiems^).  MIL- 
STD-881B  is  the  primary  source  for  developing  WBS. 

1.2.2  Focus.  Although  the  need  for  improved  tracking  and  estimating  of  software  costs  has  been 
widely  recognized  by  DoD  system  acquisition  managers  and  system  development  contractors, 
cost  estimation  focused  on  a  WBS  where  software  is  considered  to  be  a  major  part  of  the 
acquisition  has  not  beer^  treated  formally.  An  effective  tool  for  managing  and  tracking  system 
development  and  support  activities  and  related  costs  is  through  the  WBS.  In  order  lo  manage 
software  costs,  a  WBS  with  emphasis  on  software  must  be  clearly  defined  and  accounted  for 
throughout  the  system  life-cycle  process.  The  WBS  approach  currently  defined  in  MIL-STD- 
881 B  for  acquisition  of  defense  materiel  items  accommodates  this  need  by  providing  for  visibility 
of  software  elements  in  defense  systems  acquisitions.  'Fliis  approach  is  comprehensive  yet  flexible 
so  that  it  can  be  tailored  and  augmented  with  the  appropriate  software  WBS  elements  depending 
upon  the  nature  of  the  system  acquisition. 

1.3  Benefits.  The  primary  bcnefiis  gained  by  using  the  software  WBS  elements  framework 
and  guidance  herein  are  the  following: 

a.  More  cffcciive  management  practices  to  reduce  software  risk. 

b.  Integration  into  existing  cost/schedule  control  systems. 

c.  Linkage  to  statistical  proce.ss  control  and  quality  management  techniques  throughout 
the  software  life  cycle. 


1.  Defense  materiel  items  will  be  referred  to  as  defense  iystems  for  the  remainder  of  this  handbook 
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d.  ItiHucncing  Research  and  Development  (R&D)  directions  based  upon  lessons  learned 
in  areas  such  as  technology  shortfalls,  labor-intensive  activities,  and  environmental 
constraints. 

e.  Accumulation  of  software  cost  data  to  aid  the  system  acquisition  and  engineering 
planning  process  including  cost  estimation,  scheduling,  and  staffing. 

f.  Calibration  or  construction  of  formal  software  cost  estimation  models. 

g.  Development  of  a  cost  estimation  management  framework  throughout  the  software- 
life  cycle  for  current  and  future  requirements, 

h.  Provision  tc  increase  awareness  of  the  significance  and  complexity  of  software 
activities  and  related  costs. 

i.  Ability  to  measure  and  troubleshoot  performance  throughout  the  life  cycle  including 
schedule,  costs,  distribution  of  effort,  and  contractor  performance  capability. 

1.4  Organization  of  the  handbook.  The  handbook  is  organized  as  shown  in  Figure  1-1. 

Sections  1,  2,  and  3  provide  the  scope,  applicable  documcnis,  and  definitions  for  the  handbook. 
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FIGURE  M.  MIL-HDBK.I7I  Organization 
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1.4.1  Section  4.  Software  WBS  elements.  Thi.s  section  describes  how  a  WBS  accommodates 
software  or  software  intensive  programs.  It  describes  in  detail  the  WBS  software  elements  and 
their  relationship  with  each  other,  with  subsystems,  and  with  common  WBS  elements. 
Representative  activities  and  deliverables  for  each  element  are  provided  as  examples.  This 
section  also  provides  a  brief  discassion  of  how  the  WBS  and  associated  performance 
measurement  concepts  can  be  used  to  enhance  program  and  risk  management. 

1.4.2  Appendix  A.  Preparation  guidance  for  work  breakdown  structure  elements  for 
software.  This  appendix  identifies  the  importance  of  collecting  software  costs  and  provides 
examples  of  a  WBS  and  the  applicable  approach  to  identify  software  elements  as  it  relates  to 
defense  systems  programs  and  contracts  formulation.  Sample  WBS  including  software  elements 
for  a  weapon  system  and  an  Automated  Information  System  (AIS)  are  provided. 

1.43  Appendix  B.  Software  characteristics  data  collection.  This  appendix  provides 
guidance  for  collecting  data  on  project  characteristics  that  collectively  characterize  the  software 
being  developed.  These  characteristics  provide  valuable  data,  which  when  collected  and  analyzed 
by  the  program  manager  (both  Government  and  Industry),  reinforces  management  indicators  with 
credible  softv/are  resource  consumption  estimates.  A  generalized  questionnaire  is  provided  that 
contains  data  items  that  are  common  to  many  existing  software  cost  estimating  models. 
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2.  APPLICABLE  DOCUMENTS 

2.1  Government  Documents. 


2.1.1  Specifications,  standards,  and  handbooks.  The  following  specifications,  standards,  and 
handbooks  form  a  part  of  this  document  to  the  extent  specified  herein.  Unless  otherwise  specified, 
the  issues  of  these  documents  arc  those  listed  in  the  current  issue  of  the  Deparinicni  Defense 
Index  of  Specifk.itions  and  Standards  (DODISS). 

STANDARDS 

MILITARY 


MIL-STD-881B 

DOD-STD-1467 
DOD  STD-2167A 
DOD-STD-2168 
DOD-STD-7935A 

HANDBOOKS 

MILITARY 

MIL-HDDK-347 

MIL-HDBK-782 

(Unless  otherwise  indicated,  copies  of  federal 
books  are  available  from  the  Standardization 
Building  ^4,  Section  D,  Philadelphia,  PA  19111 


Work  Breakdown  Structures  For  Defense 
Materiel  Items 

Software  Support  Environment 

Defense  System  Software  Development 

Defense  System  Software  Quality  Program 

DOD  Automated  Information  System  (AIS) 
Documentation  Standard 


Mission-Criti.'.ai  Computer  Resources  Software 
Support 

Software  Support  Environment 

and  military  specifications,  standards,  and  hand- 
Documents  Order  Deisk,  700  Robbins  Avenue, 
•5094.) 


2.1.2  Other  Government  documents,  drawings,  and  publicEtions.  Tlic  following  other 
Government  documents,  drawings,  and  publications  form  a  part  of  this  document  to  the  extent 
specified  herein.  Unless  otherwise  specified,  the  issues  arc  those  cited  in  the  solicitation. 
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PUBLICAI'IONS 


Contractor  Cost  Data  Reporting  (CCDR)^ 


AFLCP  800-15 
AFSCP  800-15 
AMC-P  715-8 
NAVMAT  P-5241 


Air  Force  Logistics  Command  Pamphlet 
Air  Force  Systems  Command  Pamphlet 
Army  Materiel  Command  Pamphlet 
Navy  Materiel  Command  Pamphlet 


Cosi/Schcdule  Control  Systems  Criteria  Joint  Implementation  Guide^ 


AFCCP  173-5 
AFLCP  173-5 
.4FSCr  173-5 
AMC-P  715-5 
NAVSO  P3627 
DL.\H  8400.2 
DCAA  P7641.47 


Air  Force  Communications  Command  Pamphlet 
Air  Force  Logistics  Command  Pamphlet 
Air  Force  Systems  Command  Pamphlet 
Army  Materiel  Command  Pamphlet 
Assistant  Secretary  of  the  Navy  (S&L)  Pamphlet 
Defense  Logistics  Agency  Handbook 
Defense  Contract  Audit  Agency  Pamphlet 


DOD15000.2 


Defense  Acquisition  Management  Policies 
and  Procedures 


DI-A-3023 


Contract  V'ork  Breakdown  Structure 


(UnletiS  otherwise  indicated,  copies  of  agency  pamphlets  arc  available  from  the  Standardization 
Documents  Order  De.sk,  700  Robbins  Avenue,  Building  #4,  Section  D,  Philadelphia,  PA  19111- 
5094.) 

2.2  Non-Government  Publications.  The  following  document(s)  form  a  part  of  this  document 
to  the  extent  specified  herein. 

PUBLICATION 

ANSI/IEEE  Std  610.12-1990  Software  Engineering  Terminology 

ANSI/IEEE  Std  1016-1987  IEEE  Recommended  Practices  for  Software 

Design  Description. 


(Non  -  Government  standards  and  other  publications  arc  normally  available  from  organizations 
that  prepare  or  distribute  the  documents.  These  documents  also  may  be  available  in  or  through  li¬ 
braries  or  other  informational  services.) 

1.  This  publication  is  one  and  the  same  document  for  ai  jOini  publication  numbers  listed. 

2.  Same  as  note  1 . 
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3.  ACRONYMS  AND  DEFINITIONS 

3.1  Acronyms  and  definitions  used  in  this  handbook.  The  acionyni.s  used  in  this  handbook 


are  defined  as  follows: 

ACWP 

- 

Actual  Cost  of  Work  Performed 

AIS 

- 

Autorr.  ited  Information  System 

ANSI 

- 

American  National  Standards  Institute 

BCWP 

- 

Budgeted  Cost  for  Work  Performed 

BCWS 

- 

Budgeted  Cost  for  Work  Scheduled 

CASE 

Computer  Aided  Software  Engineering 

C/SCSC 

Cost/Schedule  Control  Systems  Criteria 

C/SSR 

Cost/Schedule  Status  Report 

CCB 

Configuration  Control  Board 

CDR 

Critical  Design  Review 

CCDR 

Contractor  Cost  Data  Reporting 

CDRL 

Contract  Data  Requirements  List 

Cl 

Configuration  Item 

CM 

Configuration  Management 

CFS 

Contractor  Furnished  Software 

CLIN 

Contract  Line  Item  Number 

COTS 

Commercial  -  off  -  the  -  shelf 

CPR 

Cost  Performance  Report 

CSC 

Computer  Software  Component 

CSCI 

- 

Computer  Software  Configuration  Item 

CWBS 

- 

Contract  Work  Breakdown  Stnicture 

DID 

- 

Data  Item  Description 

DoD 

- 

Department  of  Defense 

DODISS 

- 

Department  of  Defense  Index  of  Specifications 

Standards 

DSSE 

- 

Developmental  Software  Support  Environment 
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Engineering  Change  Proposal 

ElA 

- 

Electronics  Industries  Association 

FCA 

* 

Functional  Configuration  Audit 

FCHR 

- 

Functional  Cost  Hourly  Report 

FOR 

' 

Formal  Qualification  Review 

FQT 

- 

Formal  Qualification  Test 

GFE 

” 

Government  Furnished  Equipment 

GPS 

- 

Government  Furnished  Software 

HWCI 

Hardware  Configuration  Item 

ICD 

Interface  Control  Document 

IDD 

Interface  Design  Document 

IEEE 

Institute  of  Electrical  &  Electronics  Engineers 

IRS 

Interface  Requirements  Specification 

KSLOC 

Thousand  Source  Lines  of  Code 

LL 

Lower  Levels 

LCSSE 

Life  Cycle  Software  Support  Environment 

NOR 

Notice  of  Revision 

OT&E 

Operational  Test  and  Evaluation 

PCA 

Physical  Config  -ration  Audit 

PDR 

Preliminary  Design  Review 

PDL 

Program  Design  Language 

PM 

Project  Manager 

PMP 

Prime  Mission  Product 

POI 

- 

Program  of  Instruction 

QDR 

- 

Quality  Deficiency  Report 

R&D 

- 

Research  and  Development 

RFP 

- 

Request  for  Proposal 

SCN 

Specification  Change  Notice 

SDD 

- 

Software  Design  Document 
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SDF 

- 

Software  Development  Filc/Foldct 

SDL 

Sofiv/atc  Development  Library 

SDP 

Software  Development  Plan 

SDR 

Systems  Design  Review 

SDRB 

Solicitatioii  Data  Review  Board 

SOW 

Statement  of  Work 

SPCR 

Software  Problem  Change  Repoii 

SOL 

Structure  Query  Language 

SOPP 

Software  Quality  Program  Plan 

SRR 

System  Requirements  Review 

SRS 

Software  Requirements  Specification 

SSA 

Software  Support  Activity 

SSFivI 

Software  Standards  and  Procedure  Manual 

SSR 

Software  Specification  Review 

STR 

Software  Test  Report 

STD 

Software  Test  Description 

STP 

Software  Test  Procedures 

TCM 

- 

Total  Quality  Management 

TRR 

• 

Test  Readiness  Review 

VDD 

- 

Version  Description  Document 

WBS 

. 

Work  Breakdown  Structure 
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3.2  Application  sofiware.  ANSI/IEEE  Std  610.12  -  1990:  “Software  designed  to  fulfill 
specific  needs  of  a  user;  e.g.,  software  for  navigation,  payroll,  or  process  control.  Contrast  with: 
.system  software.” 

3.3  Commou  W3S  eUtments.  These  are  WBS  elemenus  that  arc  applicable  to  ail  types  of 
defense  systems  (e.g.,  data,  training,  system  engineering/program  management,  peculiar  support 
equipment,  industrial  facilities).  The  definition  for  the  common  WBS  elements  arc  provided  in 
Section  III  of  MIL-STD-SSIB. 

3.4  Conti'act  work  breakdown  .structure  (CWBS).  MIL-STD-881B:  “Qjntract  work 
breakdown  structure  is  defined  as  the  complete  work  breakdown  structure  foi  a  contract;  i.e.,  the 
DoD  appioved  work  breakdown  structure  for  reporting  purposes  and  its  discretionary  extension  to 
the  lower  levels  by  the  contractor  in  accordance  with  this  standard  [M1L-STD-881B)  and  the 
contract  work  ciatement.”  This  handbook  generally  is  referring  to  CWBS. 

3.5  Contractor.  DODI.5000.2;  “An  entity  in  private  industry  that  enters  into  contracts  with 
the  Government.  In  this  instruction,  the  word  may  al.so  apply  to  Government-owned, 

C-'"'crnrr?':!  operated  activities  that  perform  work  on  major  defense  programs.” 

3.6  Cost  sinalysis  activity.  The  command  activity  responsible  for  cost  estimating,  monitoring, 
and  providing  assistance  with  cost  reporting  selection  criteria.  The  cost  analysis  activity  also 
provides  assistance  in  developing  contract  peculiar  clauses  and  data  requirements  selection. 

3.7  Design  entities.  ANSI/IEEE  Std  1016-1987.  “A  design  entity  is  an  element  (compor.cni) 
of  a  design  that  is  structurally  and  functionally  distinct  from  other  elements  and  that  is  separately 
named  end  referenced.  Design  entities  result  from  a  decomposition  of  the  software  system 
requirements.  The  objective  is  to  divide  the  system  into  separate  components  that  can  be 
considered,  implemented,  changed,  and  tested  with  minimal  effect  on  other  entities”.  Design 
Entities  include  objects,  CSC(s),  modules,  classes...  etc.. 

3.8  Firmware.  DOD-STD-2167A:  “The  combination  of  a  hardware  device  and  computer 
instructions  or  computer  data  that  reside  as  read-only  software  on  the  hardware  device.  The 
software  cannot  be  readily  modified  under  program  control.” 

3.9  Procuring  activity.  DODI, 5000.2:  “The  subordinate  command  in  which  the  Procurement 
Contracting  Officer  is  located.  It  may  include  the  program  office,  related  functional  support 
offices,  and  procurement  offices.  Examples  are  the  Army  Missile  Command,  Naval  Sea  Systems 
Command,  and  Air  Force  Electronic  Systems  Division.” 
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3.10  ProgiYin  work  breakdown  structure.  MIL-STD-881B:  “'Covers  *he  entire  acquisition 
cycle  cf  fl  program  and  consists  of  at  least  the  first  three  levels  of  a  WBS  prescribed  by  MIL-STD- 
B81B  and  its  evttension  by  the  DOD  component  and/or  contractor.  The  program  WBS  has 
uniform  clement  icrminolcgy,  definition,  and  placement  in  the  family-tree  structure.  These  levels 
have  been  organized  within  the  following  categories  of  defense  materiel  items:” 

a.  Aircraft  systenr: 

b.  Elcctronic/Aulomated  software  systems 

c.  Miffsilc  systems 

d.  Ordnance 

c.  Ship  systems. 

f.  Space  systems. 

g.  Surface  vehicle  systems 

3.11  Software  .support  activity  (SSA).  MIL-HDBK-347:  “The  DoD  or  military  service 
organization  responsible  for  the  software  support  of  designated  MCCRs”  (Mission  -  Critical 
Computer  Resources).  This  document  expands  on  this  definition  tc  include  non-mission  critical 
computer  resource  systems  which  includes  AIS. 

3.12  System  softv/are.  ANSI/IEEE  Std  610.12  - 1990:  “Software  designed  to  facilitate  the 
operation  and  maintenance  of  a  computer  system  and  its  associated  programs;  e.g.,  operating 
systems,  built  in  test,  utilities  which  executes  as  part  of  the  system.  Contrast  with:  application 
software.’ 

3.13  Work  breakdown  sinicture  (WBS).  MJL-STD-8819:  “A  product-oriented  family  tree 
composed  of  hardware,  scftvjare,  services,  data,  and  facilities  which  results  from  system 
engineering  ciforts  during  the  development  and  prr>duction  of  a  defense  materiel  item,  and  which 
completely  defines  the  program.  A  work  breakdown  structure  displays  and  defines  the  product(s) 
to  be  developed  or  produced  and  relates  the  elements  of  work  to  be  accomplished  to  each  other 
and  to  the  end  product.” 
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4.  WBS  ELEMENTS  FOR 
SOFTWARE  DEFINITIONS 

4.1  WBS  overview.  The  work  breakdown  structure  is  the  basis  for  communication 
throughout  the  acquisition  process.  It  provides  the  common  link  unifying  the  planning, 
scheduling,  cost  estimating,  budgeting,  contracting,  configuration  management,  and  performance 
reporting  disciplines,  A  typical  work  breakdown  structure  for  a  defense  system  composed  of 
hardware,  software,  and  common  WBS  elements  (i.e.,  system  engineering/program  management 
and  system  test  and  evaluation, ...  etc.)  is  illustrated  by  figure  4-1.  The  elements  identified  in  this 
figure  are  represented  generically.  The  actual  element  nomenclature  would  be  specified  for  the 
particular  defense  system  category;  e.g.,  aircraft  system,  electronic  system,  or  ship  system. 


4.2  Defease  System.  The  defense  system  encompasses  all  the  Prime  Mission  Product 
(PMP)  and  common  WBS  elements  for  tne  specifie<i  d-fense  system  category  as  defined  in  MIL* 
STD-881  B.  The  common  WBS  elements  are  those  elcme  ts  applicable  to  all  types  of  defense 
systems.  The  common  WBS  elements,  softwa/e  clemonts  and  associated  lower  Icve  extenLoons 
are  fiirthcr  described  in  this  handbook.  In  defense  systems  that  consist  of  several  subsystems,  each 
subsystem  must  be  identified  separately  with  its  associated  hardware  and  software  component, 
'fhe  actual  name  of  each  subsystem  shou!  f  be  specified  (i.e.,  ‘launch  and  g  uidance”  or 
“navigation/guidance”). 
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Subordinate  to  the  PMP  arc  the  hardware  subsystem  and  software  (application  and  system) 
elements.  Each  subsystem  (i.e.,  sensors,  communications,  or  navigalion/guidance)  can  be  an 
aggregation  of  hardware  and  software  component.  Each  WBS  element  for  software  is  composed 
of  one  cr  more  builds  and  is  further  defined  as  a  Computer  Software  Configuration  Item  (CSCI). 
The  software  extension  is  further  described  in  this  handbook. 

4.2.1  Prime  Mission  Product  (PMP).  The  PMP  element  refers  to  the  hardware  and  software 
used  to  accomplish  the  primary  mission  of  the  defense  materiel  item.  It  includes  all  integration, 
assembly,  test  and  checkout,  as  well  as  all  technical  and  management  activities  associated  with 
individual  haidware/softwarc  elements.  Also  included  are  integration,  assembly,  test  and 
checkout  associated  with  the  overall  PMP.  When  the  electronic/automated  software  system 
comprises  several  PMPs,  each  will  be  listed  separately  at  the  same  level.  Also  included  are  all 
whole  and  partial  prime  contractor,  subcontractor,  and  vendor  breadboards,  brassboards,  .software 
prototypes  and  qualification  test  units.  It  also  includes  the  design,  development  and  production  of 
complete  units  (i.e.,  the  prototype  or  operationally  configured  units  which  satisfy  the 
requirements  of  their  applicable  specification(s),  regardless  of  end  use).  It  excludes  only  those 
“less  than  whole”  units  (e.g.,  test,  spares,  etc.)  consumed  or  planned  to  be  consumed  in  support  of 
system  level  tests.  This  element  also  includes  factory  special  test  equipment,  special  tooling, 
development  software  support  environment,  and  production  planning  required  to  fabricate  the 
rivif'  naruware  anu  soiiware.  Duplicate  or  modified  factory  special  test  equipment  and/or 
programming  support  environment  delivered  to  the  government  for  depot  repair  and  post 
deployment  software  support  is  excluded  and  should  be  included  in  the  peculiar  support 
equipment  element. 

4.2.1. 1  Subsystem.  This  element  refers  to  all  hardware  and  software  components  of  the 
specific  subsystem,  including  all  associated  special  test  equipment,  special  tooling,  production 
planning,  programming  environments  and  all  technical  and  management  activities.  The  software 
component  element  consists  of  the  applications  and  system  software  required  to  direct  and 
maintain  the  specific  subsystem.  All  effort  directly  associated  with  the  remaining  same  level  and 
the  integration,  assembly,  test  and  checkout  of  these  elements  into  the  PMP  is  excluded. 

4.2.1.1.1  Hardware  Component  This  element  refers  to  the  mechanical,  electrical,  and 
electronic  items  of  the  particular  subsystem.  TTie  software  component  element  refers  to  all 
software  that  is  an  integral  part  of  the  hardware  subsystem  specification  or  specifically  designed 
and  developed  for  :  josystem  test  and  evaluation. 

4.2.1.1.2  Software  Component  This  element  refers  to  all  software  that  is  an  integral  part  of  any 
specific  subsystem  specification,  for  example  navigation/guidance,  launc  ;.  and  control,  radar, 
sensors,  data  displays  <yroll  and  personnel.  This  excludes  software  that  is  specifically  designed 
and  developed  for  system  test  and  evaluation.  Tnis  software  can  be  an  aggregation  of  application 
and  system  software. 
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4.2.2  PMP  software  WBS  dements.  The  following  is  a  description  of  the  PMP  software 
WBS  elements  defined  within  the  WBS  framework.  The  software  WBS  elements  are  described 
generically  and  apply  to  each  type  of  defense  system  specified  in  MIL-STD-SSIB.  The 
associated  activities  and  deliverables^  for  which  the  cost  data  are  collected  are  listed  with  each 
software  WBS  description.  All  formal  products  and  deliverables  will  be  specified  as  per  DD 
Form  1423,  prepared  in  accordance  with  DOD-STD-2167A,  DOD-STD-1467,  or  other  applicable 
standards  and  tailored  to  the  specific  application.  Although  the  lower  level  software  eiemcnis  are 
depicted  as  being  associated  with  the  PMP  application  software  in  figure  4-2,  they  are  represented 
and  described  generically  and  apply  as  well  to  the  respective  lower  level  for  the  subsystem 
component  software  element  and  for  the  PMP  system  software  element.  A  distinction  is  made 
between  reporting  and  collecting  data.  This  is  disussed  in  section  4.3.1  and  other  sections.  When 
reusable  software  such  as  commercial-off-the-shelf  (COTS)  or  Government  Furnished  Software 
(GFS),  or  software  specifically  developed  for  reuse,  are  used  throughout  the  system,  the  cost 
associated  with  the  development,  integration,  and  maintenance  should  appear  only  once  and  be 
noted  in  the  appropriate  software  WBS  element.  (Note:  COTS,  GFS,  and  reused  software  costs 
associated  with  integration  and  test  should  be  counted  every  time  it  is  integrated  and  tested  in  the 
different  applications.  Costs  should  be  counted  only  once  for  development  and  maintenance.) 

4  2. 7  1  PMP  application  software.  Application  software  is  defined  as  software  that  is 
specifically  produced  for  the  functional  use  of  a  computer  system  (Ref.  ANSI/IEEE  Sid  610.12- 
1990).  Examples  are  battle  management,  weapons  control,  and  data  base  management.  This 
element  refers  to  all  effort  required  to  design,  develop,  integrate  and  checkout  the  PMP 
applications,  builds  and  computer  software  configuration  items  (CSCIs),  not  including  the  non¬ 
software  portion  of  PMP  firmware  development  and  production.  This  excludes  all  software  that 
is  an  integral  part  of  any  specific  hardware  subsystem  specification.  It  is  important  to  note  that  all 
software  that  is  an  integral  part  of  any  specific  hardware  subsystem  specification  or  specifically 
designed  and  developed  for  system  test  and  evaluation  should  be  identified  with  that  system  or 
subsy,stem.  hen  software  is  part  of  a  system  or  subsystem,  it  may  be  appropriate  to  collect  lower 
level  information  when  it  exists.  In  such  cases,  the  structure  defined  in  figure  4-2  should  be  used. 

4.2.2.2  PMP  system  software.  System  software  is  defined  as  software  designed  for  a  specific 
computer  system  or  family  of  computer  systems  to  facilitate  the  development,  operation,  and 
maintenance  of  the  computer  system  and  associated  programs  (i.e.,  operating  systems,  compilers, 
and  utilities  (refer  ANSI/IEEE  Std.  610.12-1990).  This  element  refers  to  all  effort  required  to 
design,  develop,  integrate,  and  check  out  the  system  software  including  all  software  developed  to 
support  any  PMP  application  software  development.  This  excludes  all  software  that  is  an  integral 
part  of  a  specific  hardware  subsystem  specification  or  specifically  designed  and  developed  for 
system  test  and  evaluation.  The  system  software  can  consist  of  multiple  software  builds.  The 
structure  shown  in  figure  4-2  should  be  used  when  lower  level  information  is  desired. 


1.  Activities  and  deliverables  listed  are  provided  as  typical  examples  only  and  do  not  preclude  any  contract 
dependent  requirements  (i.e.,  all  DOD-STD-2167A  d.Ma  requircment.<;). 
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FIGURE  4-2.  Lower  level  software  WBS  elements 
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4.23  IntegratioiJ,  Assembly,  Teot  ao'd  Checkout  In  ilioiic  instances  in  which  an 
integration,  assembly,  test  and  checkout  element  (figure  4-3)  is  used  » Appendices  A  through  G  of 
MIL-STD-881B),  it  will  include  all  effort  of  technical  and  functirjnal  activities  associate'!  with  the 
design,  development,  and  production  of  a  development  software  support  environment  and  support 
software  required  to  assemble  the  equipment  (hardware/softwarc)  elements  into  a  prime  mission 
product  (hardware/software)  as  a  whole  and  not  directly  part  of  any  other  individual  element. 
Integration,  assembly,  test  and  checkout  includes  all  effort  associated  with  the  following: 

•  Integration  of  PMP  software 

•  The  conduct  of  production  (hardware/softwarc)  acceptance  testing 

•  Acquisition  and  development  of  Development  Software  Suppoit  Environment 
(DSSE). 

When  an  integration,  a.sscmbly,  test  and  checkout  element  is  utilized  at  lower  levels  of  the 
contract  work  breakdown  structure,  it  will  be  summarized  into  the  next  higher  level  equipment 
(hardware/software)  work  breakdown  structure  clement  and  should  never  be  summarized  dirccily 
into  a  level  3  integration,  assembly,  test  and  checkout  element.  In  the  case  of  software,  the 
integration,  test  and  checkout  activity  at  the  CSCi  level  and  below  should  be  included  at  the  levels 
as  shown  in  thij«  handbook.  The  structure  shown  in  figure  4-2  should  be  used  when  it  is  desired  to 
vwlLv-, . .  level  information. 


FIGURE  4«3,  Integration,  Assembly,  Test 
ana  Checkout  WBS 


4.23.1  Development  Software  Support  Environment  (DSSE).  This  refers  to  all  computer 
hardware  and  support  software  that  is  specifically  developed  or  acquired  to  develop  the  mission 
software.  Included  in  this  element,  e.g.,  are  compilers,  loaders,  CASE  tools,  metric  tools, 
software  licenses  and  other  computer  resources  that  arc  determined  to  be  essential  in  developing 
the  mission  software.  The  cost  associated  with  this  clement  is  considered  part  of  the  CSCI  it 
supports,  or  if  more  than  one  CSCI  is  mvolvcd  it  should  be  identified  as  a  DSSE  element  and 
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incliicicci  under  the  integration,  assembly,  test  and  checkout  element.  Included  in  this  element  is 
the  cost  for  maintaining  and  operating  the  softv/are  reuse  library. 

If  the  DSSE  equipment  is  to  be  transitioned  to  the  Government  for  post  deployment  software 
support,  the  cost  associated  with  the  acquisition  should  be  included  in  this  element  and  only 
appear  once.  If  this  equipment  is  to  be  duplicated  or  modified,  then  the  additional  cost  should  be 
included  in  the  Life  Cycle  Software  Support  Environment  (LCSSE)  element  which  is  applied  to 
the  common  element  Peculiar  Support  Equipment. 

4.3  Software  development  approach.  Software  development  is  a  compien  process, 
typically  consisting  of  a  number  of  parallel  devclopmenis  at  the  subsystem  level.  For  many 
projects  the  development  process  is  a  scries  of  parallel  ac:ivities  with  several  individual  sub¬ 
system  software  products  undergoing  development  at  any  one  t'rnc.  In  a  software  development 
cycle,  lower  level  software  elements  (figure  4-2),  can  be  replicated  within  a  project  many  times 
depending  on  the  complexity  of  development.  The  complexity  of  the  development  process  can  be 
managed  and  controlled  by  decomposing  and  organizing  the  system  into  smaller  development 
subsystem  software  components  or  builds.  The  builds  provide  a  snapshot  of  the  system  at  any 
point  in  the  acquisition  process.  This  affords  the  developer  an  opportunity  to  gauge  overall 
progress  before  the  system  is  complete.  The  system  can  also  be  put  into  operation  in  increments  or 
builds  as  a  series  of  tested  and  delivered  capabilities  that  are  integrated  throughout  the  system  life 
cycle.  These  may  be  further  organized  into  CSCIs,  which  are  products  that  meet  specific  program 
requirements.  The  software  WBS  elements  described  in  this  handbook  permit  Decomposition  of 
the  software  project  from  a  system  to  prime  mission  products. 

In  software  development  as  with  many  engineering  disciplines,  the  product  decomposition 
below  the  CSCI  level  is  performed  by  software  professionals  (such  as  designers,  coders).  The 
software  product  is  a  token  that  is  passed  along.  Software  is  refinetJ  anr'  elaborated  from  the 
software  requirements  analy.sis,  the  specification,  the  design,  the  code. 

The  initial  partitioning  of  the  requirements  is  the  raw  material  from  which  the  design  and 
ultimately  the  code  evolve.  The  requirements  specification  and  design  are  integral  to  the  software 
product.  This  is  readily  apparent  when  Ada  program  design  language  (PDL)  is  used.  Software  is 
the  refinement  and  elaboration  of  the  requirements  and  the  design.  These  lower  levels  do  not 
imply  a  design  methodology,  but  rather  they  are  data  taps  into  any  process,  (e.g.,  waterfall, 
spiral,  incremental,  evolutionary).  These  taps  are  methodology  independent.  Figure  4-4  is  an 
example  of  software  WBS  lower  level  extension  rclate.d  to  a  spiral  model.  The  software  WBS 
dements  are  primarily  related  to  the  software  development  process  for  a  defense  system. 
Examples  of  their  associated  Lower  Level  (LL)  are  described  and  delineated  giaphically  in  more 
detail  throughout  the  following  subparagraphs.  This  handbook  also  applies  to  the  development  or 
support  of  deliverable  software  to  be  implemented  in  firmware.  The  WBS  software  elemenis  do 
not  apply  to  the  development  of  the  hardware  element  of  firmware. 
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FIGURE  4-4.  Notiona!  taps  into  a  spiral  model 
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4.3.1  Software  lower  level  extensions.  The  software  element  of  the  defense  system  can  be 
further  decomposed  at  the  CSCI  level  and  below  as  illustrated  in  figure  4-2.  The  software  WBS 
elements,  as  identified  in  this  handbook,  provide  insight  into  and  consistency  in  software 
management  information  including  cost  and  schedule  tracking  at  or  below  the  CSCI  level.  This 
handbook  provides  a  common  reference  framework  within  which  contractors  developing  or 
supporting  software  plan  or  report  the  cost  data  associated  with  elements  of  software  development 
and  support  practices.  It  is  recommended  that  contractors  collect  cost  management  information 
associated  with  software  lower  level  elements.  Software  cost  and  schedule  reporting  will  be  to  a 
level  appropriate  to  the  risk,  cost,  schedule,  and  interest  of  the  program.  The  lower  level 
extension  for  software  WBS  elements  is  used  as  a  common  collecting  framework,  consistent  with 
DoD  software  development  and  acquisition  policy. 

4.3.2  Software  build.  A  software  build  is  an  aggregate  of  one  or  more  CSCIs  that  satisfies  a 
specific  set  or  subset  of  requirements  based  on  development  of  software  as  defined  in  DOD-STD- 
2167A.  When  an  incremental,  spiral,  or  other  software  development  method  is  used,  multiple 
builds  may  be  necessary  to  meet  program  requirements.  A  build  is  a  separately  tested  and 
delivered  product.  Within  builds  are  CSCIs.  When  a  build  is  complete,  a  portion  or  all  of  one  or 
more  CSCI  will  be  completed.  Therefore,  a  CSCI  may  appear  in  more  than  one  buila,  but  will  be 

morf  fiinrtional  as  each  build  is  completed. 

4.33  Computer  software  configuration  item.  An  aggregation  of  software  or  any  of  its 
discrete  portions  that  satisfy  an  end  use  function  and  have  been  designated  by  the  Government  for 
configuration  management.  CSCIs  are  the  major  software  products  of  a  system  acquisition  that 
arc  developed  in  accordance  with  DOD-STD-2167A.  This  includes  reusable  software 
components  such  as  commercial  off-the-shelf  software,  Government-furnished  software,  or 
software  specifically  developed  for  reuse.  The  CSCI  element  can  be  composed  of  design  entities 
consisting  of  computer  software  components  (CSCs)  per  DOD-STD-2167A,  or  objects,  classes 
modules,  etc.  The  distinct  parts  are  functionally  or  logically  identified  by  engineering  decisions 
for  convenience  in  designing  and  specifying  a  complex  CSCI.  It  includes  the  effort  associated 
with  the  requirements  analysis,  design,  coding  and  testing,  design  entity  integration  and  testing, 
CSCI  testing,  and  software  problem  resolution  of  each  CSCI. 

4.33.1  Requirements  analysis.  This  applies  to  the  system  requirements  (as  it  pertains  to 
software)  and  software  requirement  analysis  activities  as  stated  in  DOD-STD-2I67A.  The 
software  requirements  analysis  is  the  process  by  which  a  complete  set  of  engineering  and 
interface  requirements  are  defined  for  each  CSCI.  Representative  activities  and  deliverables  are  as 
follows: 

Activities: 

•  Analysis  of  preliminary  software  requirements. 

•  Identification  and  allocation  of  software  requirements  into  CSCIs. 
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•  Analysis  of  prelirninary  interface  requirements. 

•  Identification  and  resolution  of  interfa.'^e  requirements. 

Deliverables:  Formal  deliverables  are  specified  in  DD  Form  1423. 

•  Formal  minutes  of  review  meetings,  including  presentation  materials. 

•  Interface  Requirements  Specifications  (IRS). 

•  Software  Requirements  Specification  (SRS). 

•  Software  requirements  analysis  technical  reports. 

(For  the  formal  deliverables,  costs  associated  with  the  administrative  preparation,  review,  and 
distribution  are  excluded.  Tliese  costs  are  included  in  the  appropriate  data  WBS  elements.) 

4.3  J.2  Design.  Software  design  is  the  process  of  decomposing  a  high-level  abstract 
rcquii'ement  into  lower  level  software  elements.  Preliminary  design  and  detailed  design  activities 
are  accomplished  to  map  out  high-level  as  well  as  low-level  strategies  for  allocating  requirements 
from  Software  Requirements  Specifications  (SRSs)  and  Interface  Requirements  Specifications 
(IRSs)  for  each  CSCI  to  design  entities,  e.g.  objects,  classes,  modules,  CSC(s),  etc. 
Representative  sample  activities  and  deliverables  are  as  follows: 

Activities: 

•  Creating  and  maintaining  Software  Development  Files/Folders  (SDFs) 

•  Analysis  of  preliminary  software  design. 

^  Derive  and  map  out  high  (top)  level  software  design  specifications. 

•  Devise  and  map  out  low  level  (detailed)  software  design  specifications. 

•  Analysis  of  preliminary  interface  design  specification. 

«  Define  and  de.scribc  interface  design  specification. 

•  Generate  input  to  software  test  planning. 

•  Formalize  test  requirements  for  design  entities. 

Deliverables:  Formal  deliverables  arc  specified  in  DD  Form  1423. 

•  Formal  minutes  of  review  meetings,  including  presentation  materials. 

•  Design  analysis  technical  reports. 

(For  the  formal  deliverables,  costs  associated  with  the  administrative  preparation,  review,  and 
distribution  are  excluded.  These  costs  arc  included  in  the  appropriate  data  WBS  elements.) 

4.33.3  Coding  and  design  entity  testing.  Software  coding  is  the  process  of  creating  a 
representation  of  the  software  design  into  a  program  language  that  may  then  be  converted 
mechanically  (i.c.,  by  compilation)  to  an  acceptable  machine-executable  representation.  Each 
design  entity  is  cotied  and  subsequently  tested  to  ensure  that  it  satisfies  its  specific  requirement. 
Representative  activities  and  deliverables  arc  as  follows: 
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Activities: 

•  Maintaining  SDFs. 

•  Coding  and  compiling  activities. 

•  Conduct  testing  and  analysis. 

•  Code  walk-through  activities. 

•  Performing  compliance  checks  to  coding  conventions. 

•  Developing  lower  level  design  entities  test  and  integration  procedutes 
Deliverables:  Formal  deliverables  are  specified  in  DD  Form  1423. 

•  Source  code  listings. 

•  SDFs. 

(For  the  forma!  deliverables,  costs  associated  with  the  administrative  preparation,  review,  and 
distribution  are  excluded.  These  costs  are  included  in  the  appropriate  data  WBS  elements.) 

4.33.4  Design  entity  integration  and  testing.  Integration  or  building  of  design  entities  into  a 
CSCI  is  performed  and  testing  of  lower  level  threads  is  conducted  to  verify  that  algorithms  and 
data  employed  in  interfacing  each  design  entity  is  correctly  specified  and  implemented.  Tliis 
cusuics  luai  wijcii  combined  into  larger  builds,  they  demonstrate  compliance  with  stated 
cusiomer/user  requirements.  Representative  activities  and  deliverables  are  as  follows: 

Activities: 

•  Perform  design  entity  integration  analysis. 

•  Perform  design  entity  build  and  lower  level  thread  testing. 

■  Record  test  results. 

•  Perform  dry  run  of  formal.qualification  tests  documented  in  Software  Test  Description 
(STD). 

Deliverables:  Formal  deliverables  are  specified  in  DD  Form  1423. 

•  Formal  minutes  of  review  meetings,  including  presentation  materials. 

•  Integration  and  test  analysis  engineering  notes. 

(For  the  formal  deliverables,  costs  associated  with  the  administrative  preparation,  review,  and 
distribution  are  excluded.  These  costs  are  included  in  the  appropriate  data  WBS  elements.) 

4.33.5  CSCI  testing.  CSCI  testing  is  the  process  of  demonstrating  to  the  procuring  activity  that 
the  CSCI  can  perform  correctly  under  the  full  range  of  operating  conditions  specified  in  the 
requirements  documentation  and  that  each  CSCI  satisfies  its  specification  requirements. 
Representative  activities  and  deliverables  arc  as  follows: 

Activities: 
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•  Conduct  formal  qualification  tests. 

•  Conduct  test  analysis  and  record  test  results. 

•  Generate  input  to  the  Software  Test  Reports  (STRs). 

Deliverables:  Formal  deliverables  are  specified  in  DD  Form  1423. 

•  Formal  minutes  of  review  meetings,  including  presentation  materials. 

•  Formal  qualification  test  descriptions. 

•  Qualification  tests  analysis  engineering  notes. 

•  Software  problem  change  reports. 

(For  the  formal  deliverables,  costs  associated  with  the  administrative  preparation,  review,  and 
distribution  are  excluded,  These  costs  arc  included  in  the  appropriate  data  WBS  elements.) 

4.3J.<5  Software  Problem  Change  Report  (SPCR)  resolution.  SPCR  resolution,  also  known  as 
rework  (figure  4-5),  is  the  process  of  analyzing  and  correcting  software  problems.  The  problem  may  be 
as  a  result  of  logic  deficiencies,  non  compliance  with  previously  defined  requirements  and  design 
specifications,  or  clarifications  and  other  changes  to  previously  defined  requirements  and  design 
specifications.  This  reporting  element  begins  once  the  software  has  been  placed  under  development 
baseline  control  after  the  conduct  of  formal  qualification  testing  but  prior  to  Government/customer 
acceptance.  The  level  of  efforts  related  to  redesign,  recoding,  and  testing  are  included  in  the  WBS 
elements  described  below.  The  level  of  efforts  associated  with  the  common  WBS  element  activities  such 
as  software  data,  software  quality  assurance,  and  software  configuration  management  incurred  during  the 
problem  resolution  process  are  included  in  the  appropriate  common  WBS  software  elements. 


HGURE  4-5.  SPCR  resolution  WBS  struftturc 


43  J.6.1  Redesign.  Redesign  is  the  process  of  analyzing  and  modifying  the  software  component 
abstractions  based  on  the  SPCR,  This  element  includes  the  identification  of  deficiencies  and  reallocation 
of  software  component  structures  to  comply  with  the  previously  defined  requirements  and  specifications. 
Representative  activities  and  deliverables  arc  as  follows: 

Activities: 
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*  Analyze  the  software  prcblem^l^rt^J^ntil^e^at^eported. 

»  Make  neces3r>ry  corrections  in  design. 

Deliverables:  Foimai  deliverables  arc  specified  in  DD  Form  1423. 


*  Updated  design  specifications. 

''  Design  analysis  engineering  notes. 

•  Formal  minutes  of  review  meetings.  ’ 

(For  the  formcl  deiiverubles,  costs  associated  with  the  administrative  preparation,  review,  and 
distribution  are  excluded.  These  costs  are  included  in  the  appropriate  data  WBS  elements.) 


433.62  Recoding  and  design  entity  testing.  Recoding  is  the  process  of  recreating  the 
lepresentation  of  the  new  or  modified  software  design  into  the  established  programming  language. 
Ail  applicable  design  entities  are  recoded,  tested  and  integrated  to  ensure  that  the  identified  problems 
are  resolved  and  that  the  specific  requirements  are  satisfied.  Representative  activities  and 
deliverables  arc  as  follows: 


Activities: 

•  Update  software  development  filc.s/folders  (SDFs). 

•  Recoding  and  recompiling  activities. 

•  Design  entity  testing,  and  analysis. 

•  Code  walk-through  activities. 

»  Performing  compliance  checks  to  coding  conventions  and  software  quality  metrics. 

•  Update  lower  level  entity  test  and  integration  procedures. 

Deliverables:  Formal  deliverables  are  specified  in  DD  Form  1423. 

•  New  source  code  listings. 

•  Updated  .softv/arc  development  files/foldcrs, 

(For  the  formal  deliverables,  costs  associated  with  the  administrative  preparation,  review,  and 
distribution  are  excluded.  Tliese  costs  arc  included  in  the  appropriate  data  WBS  elements.) 

4.3.3.53  Design  entity  reintegration  and  testing.  Reintegration  of  applicable  design  entities  is 
performed.  Testing  is  once  again  conducted  to  verify  that  modifications  to  algorithms  and  data 
employed  in  interfacing  each  entity  are  correctly  specified.  Also,  additional  testing  is  conducted  to 
ensure  that  modifications  made  to  the  sofb;/arc  have  not  introduced  new  ciTors.  Representative 
activities  and  deliverables  are  as  follows: 


Activities: 

•  Update  input  to  software  test  pif  nning. 

•  Redefine  software  test  case  za  appropriate. 

•  Establish  new  test  procedures  where  necessary. 

•  Perform  design  entity  re-integration  analysis. 

•  Maintain  SDFs. 
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•  Perform  entity  rebuild  and  retest. 

Deliverables:  Formal  deliverables  arc  specified  in  DD  Form  1423. 

•  Integration  and  test  analysis  engineering  notes. 

•  Test  documentation 

(For  the  formal  deliverables,  costs  associated  with  the  rdministrative  preparation,  review,  and 
distribution  are  excluded.  These  costs  are  included  in  the  appropriate  data  WBS  elements.) 

4.3.4  CSCI  to  CSC!  integration  and  checkout  This  clement  includes  integration  and  test 
verification  and  validation  of  (he  CSCIs.  CSCI  acceptance  is  performed  and  thread  testing  is 
conducted  to  verify  that  the  algorithms  and  data  employed  for  interfacing  each  CSC!  are  correctly 
specified  and  implemented  so  that  they  can  demonstrate  compliance  with  stated  requirements. 
Representative  activities  and  deUverables  are  as  follows: 

Activitie.s: 

•  Generate  input  to  software  test  plans,  description.s,  and  procedures. 

•  Define  software  test  cases. 

•  Perform  CSCI  integ’-ation  analysis. 

•  Perform  scftv/are  build  and  test. 

•  Update  SDFs. 

Deliverables:  Formal  deliverables  are  specified  in  DD  Form  1423. 

•  Forma!  minutes  of  reviev/  meetings,  including  presentation  materials. 

•  .niegration  and  test  analysis  engineering  note.s. 

•  Source  code  listing. 

(For  the  formal  deliverables,  costs  associated  with  the  administrative  preparation,  review,  and 
distribution  are  excluded  These  costs  are  included  in  the  appropriate  data  WBS  elements.) 

4.4  Common  work  breakdown  .structure  elements.  These  level  2  elements  are  common 
to  all  types  of  defense  systems,  as  specified  in  MIL-STD-SSIB.  Tlie  common  elements 
encompass  the  areas  of  system  engineering/program  management,  system  lest  and  evaluation,  and 
training,  etc.  M1L-STD-881B  groups  several  elements  into  a  collection  referred  to  as  Common 
WBS  (refer  to  figure  4-6).  Examples  of  their  associated  level  3  and  lower  level  software  element 
extension,  where  applicable,  are  described  and  delineated  graphically  in  more  detail  throughout 
the  following  subparagraphs. 
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FIGURE  4-6.  Common  WES  elements 


4.4.1  System  engineering/program  management  System  engineering/program 

('♦“oiire  4.7't  refers  to  the  software  related  activities  associated  with  the  overall 
system  engineering,  technical  control,  and  business  management  of  the  particular  program.  This 
inciudes  planning,  directing,  and  controlling  efforts  of  design  engineering,  reliability  engineering, 
maintainability  engineering,  human  factors  engineering,  logistics  engineering,  speciality 
engineering,  software  engineering,  production  engineering,  and  integrated  test  planning.  The 
program  management  elements  include  planning,  directing,  coordinating,  and  monitoring  tiie 
development  and  support  efforts  associated  with  the  total  system  software. 
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FIGURE  4-7.  System  engineering/program  management  WBS 

4.4.1. 1  Software  project  management.  Software  project  management  refers  to  the  business 
and  administrative  planning,  organizing,  directing,  coordinating,  controlling,  and  approval  actions 
designated  to  accomplish  overall  project  objectives  that  are  associated  with  specific  software 
elements.  Representative  activities  and  deliverables  are  as  follows; 

Activities: 

*  Define  and  prepare  overall  task  execution  plans  and  project  milestones. 

*  Monitor  and  direct  various  project  activities. 

*  Prepare  and  report  project  progress  and  status. 

*  Control  project  cost-related  activities. 

*  Prepare  and  report  project  funding  expenditures. 

*  Direct  and  participate  in  all  system  and  activity  review  meetings  as  necessary. 

*  Prepare  and  report  software  metrics  data  and  status. 

*  Support  &.  facilitate  Government  software  review  teams. 

Deliverables:  Formal  deliverables  are  specified  in  DD  Form  1423. 

*  Prepare  formal  responses  to  Government  queries. 

*  Prepare  and  submit  progress  reports. 

(For  the  formal  deliverables,  costs  associated  with  the  administrative  preparation,  review,  and 
distribution  are  excluded.  These  costs  are  included  in  the  appropriate  data  WBS  elements.) 

4.4.1.2  System  engineering.  The  system  engineering  element  is  defined  as  the  technical  and 
management  efforts  of  directing  and  controlling  an  integrated  engineering  effort  of  a  system  or 
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program.  This  element  encompasses  the  system  engineering  effort  to  define  the  system  and  the 
integral  planning  and  control  of  the  technical  program  efforts  of  design  engineering,  specially 
engineering,  production  engineering,  and  integrated  test  planning.  This  element  includes,  but  is 
not  limited  to,  the  system  engineering  effort  to  transform  an  operatirnal  need  or  statement  of 
deficiency  into  a  description  of  system  (hardwarc/softwarc)  requirements  and  a  preferred  system 
configuration  and  the  technical  planning  and  control  effort  for  planning,  monitoring,  measuring, 
evaluating,  directing,  and  replanning  the  management  of  the  technical  program.  It  specifically 
excludes  the  actual  design  engineering  and  the  requirements  analysis  below  the  CSCI  level. 
Representative  activities  and  deliverables  are  as  follows: 

Activities: 

•  System  level  definition  and  requirements  analysis. 

•  Design  integrity  analysis. 

•  Preparation  of  systems  engineering  management  plan  and  specification. 

•  Program  risk  ana'ysis. 

•  Participate  and  conduct  technical  reviews  (e.g.,  system  requirements  reviews,  system 
design  reviews). 

Deliverables:  Formal  deliverables  are  specified  in  DD  Form  1423. 

'  Tct-iiuicai  review  of  engineering  notes. 

•  System  engineering  management  plan. 

•  Technical  reports  and  system  engineering  analysis  notes. 

(For  the  forma!  deliverables,  costs  associated  with  the  administrative  preparation,  review,  and 
distribution  are  excluded.  These  co.sts  are  included  in  the  appropriate  data  WBS  elements.) 

4.4.1.2.1  Software  engineering  management.  The  software  engineering  eleirjent  refers  to  the 
technical  and  management  efforts  of  directing  and  controlling  the  total  software  related 
engineering  effort  of  a  system.  This  includes  planning  and  control  of  all  defense  system  software 
engineering  efforts,  excluding  the  actual  design,  and  some  hardware  engineering  efforts  to  the 
extent  of  their  direct  relationship  to  and  impact  on  the  software  engineering  efforts.  This  element 
also  includes  analysis  to  determine  the  best  allocation  ofsyslcm  requirements  between  hardware, 
software,  and  personnel  in  order  to  partition  the  system  into  hardware  configuration  items 
(HV/CIs)  and  CSCIs.  Representative  activities  and  deliverables  are  as  follows: 

Activities: 

•  Analyze  system  definition  and  requirements. 

•  Preparation  and  execution  of  Software  Specification  Reviews  (SSRs). 

•  Prepare  inputs  to  the  systems  engineering  management  plan. 

•  Define  technical  performance  measurements. 

•  Participate  in  technical  review  meetings. 

•  Define  intrasystem  and  intersystem  compatibility. 
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•  Perform  risk  analysis. 

•  Preparation  and  execution  of  software  preliminary,  critical,  design  reviews  etc. 

•  Evaluate  the  impact  of  engineering  change  proposals  (ECPs)  on  defense  system 
software. 

Deliverables:  Formal  deliverables  are  specified  in  DD  Form  1423. 

•  Formal  minutes  of  review  meetings,  including  presentation  materials. 

•  Software  engineering  management  plan. 

•  Technical  reports  and  software  engineering  analysis  notes. 

For  the  formal  deliverables,  costs  associated  with  the  administrative  preparation,  review, 
and  distribution  are  excluded.  These  costs  are  included  in  the  appropriate  data  WBS  elements.) 

4.4.1.2.2  Software  quality  assurance.  Software  quality  assurance  includes  those  tasks  that 
ensure  compliance  with  the  Government  requirements  for  development  and  implementation  of 
the  contractor’s  software  quality  program.  This  program  ensures  the  quality  of  (1)  deliverable 
software  and  its  documentation;  (2)  the  processes  used  to  produce  deliverable  software;  and  (3) 
non*deliverabie  software  as  specified  in  DOD-STD-2168.  Representative  activities  and 
nrf*  flis  follOWSI 


Activities: 

.  ♦  Generation  or  revision  of  the  Software  Quality  Program  Plan  (SQPP) 

•  Participates  in  the  Software  Development  Plan  (SDP)  development  and  review. 

•  Participation  in  Vcrificaiion  and  Validation  (V&V)  support. 

•  Participation  in  formal  reviews  and  audits. 

•  Conduct  ongoing  software  quality  evaluations  of  processes  used  in  software 
development. 

•  Prepare  and  maintain  records  of  software  quality  activities, 

•  Monitor  the  timeliness  and  appropriateness  of  software  corrective  actions. 

Deliverables:  Formal  deliverables  are  specifie<d  in  DD  Form  1423. 

•  Functional  Configuration  Audit  (FCA)  Report. 

(For  the  formal  deliverables,  costs  associated  with  the  administrative  preparation,  review,  and 
distribution  are  excluded.  These  costs  are  included  in  the  appropriate  data  WBS  elements.) 

4.4.1.2  J  Software  configuration  management  Software  configuration  management  is  a 
discipline  applying  technical  and  administrative  direction  and  surveillance  to  (1)  identify  and 
document  the  functional  and  physical  characteristics  of  CSCIs;  (2)  control  changes  to  CSCIs  and 
their  related  documentation;  (3)  audit  CSCIs  to  verify  conformance  to  specifications  and  Interface 
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Control  Documents  (ICDs);  and  (4)  record  and  report  change  processing  and  implemcniaiicn 
status  information. 

Activities: 

•  Conduct  and  maintain  configuration  status  accounting. 

•  Develop  baseline  and  version  control  for  each  CSCl. 

•  Participate  in  and  provide  input  to  FCA. 

•  Participate  in  and  provide  input  to  Physical  Configuration  Audit  (PCA). 

•  Preparation  of  ECP. 

•  Preparation  of  Specification  Change  Notices  (SCN). 

•  Generate  inputs  to  the  Software  Configuration  Management  Plan. 

«  Preparation  of  Notice  of  Revisions  (NORs) 

•  Generate  inputs  to  Version  Description  Documents  (VDDs). 

•  Participate  in  Configuration  Control  Board  (CCB)  meetings. 

Deliverables:  Formal  deliverables  are  specified  in  DD  Form  1423. 

•  Configuration  status  accounting  and  engineering  reports. 

•  Version  control  reports. 

•  Configuration  management  plan. 

(For  the  forma!  deliverables,  costs  associated  with  the  administrative  preparation, 
review,  and  distribution  are  excluded.  These  costs  are  included  in  the  appropriate  data 
WBS  elements.) 

4.4.2  System  test  and  evaluation.  The  system  test  and  evaluation  clement  (figure  4-8)  refers 
to  the  use  of  prototype,  production,  or  specifically  fabricated  hardwarc/softwarc  to  obtain  or 
validate  engineering  data  on  the  performance  of  the  system  during  the  development  phase 
(normally  funded  from  RDT&E)  of  the  program.  This  element  includes  the  detailed  planning, 
conduct,  support,  data  reduction  and  reports  (excluding  the  Contract  Data  Requirements  List 
(CDRL)  data)  from  such  testing,  and  ail  hardware/software  items  which  are  consumed  or  planned 
to  be  consumed  in  the  conduct  of  such  testing.  It  also  includes  all  efforts  associated  with  the 
design  and  production  of  models,  specimens,  fixtures,  and  instrumentation  in  support  of  the 
system  level  test  program.  NOTE:  Test  articles  which  are  compile  units  (i.e.,  functionally 
configured  as  required  by  specifications)  are  excluded  from  this  work  breakdown  structure 
elemi;nt.  All  formal  and  informal  testing  up  through  the  subsystem  level  which  can  be 
associated  with  the  hardware/software  element  are  excluded.  Acceptance  testing  Is  also 
excluded.  These  excluded  efforts  are  to  be  included  with  the  appropriate  hardware  of 
software  elements. 
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4.4.2.1  Development  test  and  evaluation.  The  development  test  and  evaluation  element  refers 
to  the  test  and  evaluation  corducted  to:  (1)  demonstrate  that  the  engineering  design  and 
development  process  is  complete;  (2)  demonstrate  that  the  design  risks  have  been  minimized;  (3) 
demonstrate  that  the  system  will  meet  specifications;  (4)  estimate  the  system 's  military  utility 
when  introduced;  (5)  determine  whether  the  engineering  design  is  supportable  (practical, 
maintainable,  safe,  etc.)  for  operational  use;  (6)  provide  test  da  s  with  which  to  examine  and 
evaluate  trade-offs  against  specification  requirements,  life  cycle  cost,  and  schedule;  and  (7) 
perform  the  logistics  testing  efforts  to  evaluate  the  achievement  of  supportability  goals,  the 
adequacy  of  the  support  package  for  the  system,  e.g.,  deliverable  maintenance  tools,  test 
equipment,  technical  publications,  maintenance  instructions,  and  personnel  skills  and  training 
requirements  etc.  Development  test  and  evaluation  includes  all  ccatractci  in-house  effort  and  ail 
effort  of  planning,  conducting  and  monitoring  by  the  developing  agency  of  the  DoD  Component. 

Ail  programs,  where  applicable,  include  models,  tests  and  associated  simulations  such  as  wind 
tunnel,  static,  drop,  and  fatigue;  integration  ground  icsis;  test  bed  aircraft  and  associated  support; 
qualification  test  and  evaluation  (QT«Si.E),  development  flight  test,  test  instrumentation, 
environmental  tests,  ballistics,  radiological,  range  and  accuracy  demonstrations,  test  facility 
operations  test  equipment  (including  its  support  equ.pmcnt),  chase  aircraft  and  support  thereto, 
and  logistics  testing. 

For  aircraft,  include  avionics  integration  lest  composed  of  the  following:  (1)  test  bench/ 
laboratory,  including  design,  acquisition,  and  iasiallation  of  basic  computers  and  lest  equipments 
which  will  provide  an  ability  to  simulate  in  the  laboratory  the  operational  environment  of  the 
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avionics  system/subsysterrs;  (2)  air  vehicle  equipment,  consisting  of  the  avionics  end/oi  other  air 
vehicle  subsystem  module})  which  ar  required  by  the  bcnch/lab  or  flying  test  bed  in  order  to 
provide  a  compatible  airframe  avionics  system/subsystem  fo^  evaluation  purposes;  (3)  flying  test 
bed,  including  requirements  analysis,  design  of  modifications,  lease  or  purchase  of  test  bed 
aircraft,  modification  of  aircraft,  installation  of  avionics  equipment  and  instrumentation,  and 
checkout  of  an  existing  aircraft  used  essentially  as  a  flying  avionics  laboratory;  (4)  avionics  test 
program,  consisting  of  the  effort  required  to  develop  test  plans/procedures,  conduct  tests,  and 
analyze  hardware  and  software  test  results  to  verify  the  avionics  equipments’  operational 
capability  and  compatibility  as  an  integrated  air  vehicle  subsystem;  and  (5)  software,  refening  to 
the  effort  required  to  design,  code,  de-bug  and  document  software  programs  necessary  to  direct 
the  avionics  integration  test.  The  software  in  figure  4-8  is  typical  for  each  element.  When 
appropriate  the  software  component  may  be  extended  according  to  the  structure  shown  in  figure 
4-2. 

4.4.2.2  Operational  test  and  evaluation.  The  operational  test  and  evaluation  element  refers  to 
that  test  and  evaluation  conducted  by  agencies  other  than  the  developing  command  to  assess  the 
prospeclive  system’s  military  utility,  operational  effectiveness,  operational  suitability,  logistics 
supporiaciiiiy  (^inciuaing  compatibility,  inter-operability,  reliability,  maintainability,  logi.siic 
requirements,  etc.),  cost  of  ownership,  and  need  for  any  modifications.  Initial  operational  test 
and  evaluation  conducted  during  the  development  of  a  weapon  system  will  be  included  in  this 
element.  This  element  encompasses  such  tests  as  system  demonstration,  flight  tests,  sea  trials, 
mobility  demonstrations,  on-orbit  tests,  spin  demonstration,  stability  tests,  qualification 
operational  test  and  evaluation  (QOT&E),  etc.,  and  support  thereto,  required  to  prove  the 
operational  capability  of  the  deliverable  system.  It  includes  contractor  support  (e.g.,  technical 
assistance,  maintenance,  labor,  material  etc.)  consumed  during  this  phase  of  testing.  It  also 
includes  performing  the  logistics  testing  efforts  to  evaluate  the  achievement  of  supportability 
goals;  the  adequacy  of  the  support  for  the  system,  c.g.,  deliverable  maintenance  tools,  test 
equipment,  technical  publications,  maintenance  instructions,  and  personnel  skills  and  training 
requirements. 

4.4.2.3  Mock-ups.  The  mock-ups  element  refers  to  the  design  engineering  and  production  of 
system  or  subsystem  mock-ups  which  have  special  contractual  or  engineering  significance,  or 
which  arc  not  required  solely  for  the  conduct  of  one  of  the  above  elements  of  testing. 

4.4.2.4  Test  and  evaluation  support.  The  test  and  evaluation  support  element  refers  to  all 
support  elements  necessary  to  operate  and  main'atn  systems  and  subsystems  during  test  and 
evaluation  which  are  not  consumed  during  the  testing  phase  and  arc  not  allocated  tc  a  specific 
phase  of  testing.  This  element  includes,  i.c.,  repairable  spares,  repair  of  repairables,  repair  parts, 
warehousing  and  distribution  of  spares  and  repair  parts,  test  and  support  equipment,  test  bed 
vehicles,  drones,  surveillance  aircraft,  tracking  vessels,  contractor  technical  support,  etc.,  not 
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allocated  to  prctxding  test  and  evaluation  elements.  Operational  and  maintenance  personnel, 
consumables,  special  fixtures,  special  instrumentation,  etc.,  which  are  utilized  and/or  consumed  in 
a  single  rdement  of  testing  and  which  should,  therefore,  be  included  under  that  element  of  testing 
are  excluded. 

4.4.2.5  Test  facilities.  The  test  facilities  clement  refers  to  those  special  test  facilities  required 
for  performance  of  the  various  dcvelopmcnia!  tests  necessary  to  prove  the  design  and  reliability  of 
the  system  or  subsyulcm.  This  clement  includes,  i.e.,  test  tank  test  fixtures,  propulsion  test 
fixtures,  white  rooms,  lest  chambers,  etc.  The  brick-and-mortar-type  facilities  identified  as 
industrial  facilities  are  excluded. 

4.43  IVaicing.  The  training  element  (figure  4-9)  is  defined  as  the  deliverable  training 
services,  devices,  accessories,  aids,  equipment,  and  parts  used  to  facilitate  instruction  through 
which  personnel  wilt  acquire  sufficient  concepts,  skills,  and  aptitudes  to  operate  and  maintain  the 
system  with  maximum  efficiency.  This  clement  includes  all  effort  associated  with  the  design, 
development,  and  production  of  deliverable  training  equipment  as  well  as  the  execution  of 
training  services.  This  element  and  its  sub-elcrncnts  specifically  exclude  the  overall  planning, 
management,  and  task  analysis  function  inherent  in  the  WBS  element  systems  engineering/' 
management. 

4.43.1  Software  training  services,  equipment,  and  facilities.  Tliis  element  refers  to  the 
training  services,  special  devices,  equipment  and  facilities  used  to  conduct  instruction  through 
which  personnel  will  acquire  sufficient  concepts,  skills,  and  aptitudes  to  operate  and  maintain  the 
software  portion  of  the  system.  This  element  includes  the  material,  courses,  and  associated 
documentation  development  necessary  to  accomplish  the  contracted  for  objective  of  training, 
(primarily  the  computer  software,  courses,  training  aids,  developed  or  constructed  solely  for  the 
training  mission).  It  encompasses  the  materials  used  for  the  purpose  of  acquainting  the  trainees 
with  the  system  and  equipment  or  establishing  trainee  proficiency.  ITiis  clement  specifically 
excludes  the  deliverable  training  data  associated  with  the  WBS  clement,  Support  Data. 
Representative  activities  end  deliverables  are  as  follows; 

Activities: 

•  Preparation  and  conduct  of  the  following: 

•  Software  installation  training. 

•  Operational  training  involving  host  and  target  execution  environment. 

•  Maintenance  training  involving  the  incorporation  of  software  updates  or  changes. 

•  Training  services  provided  for  teaching  software  functional  architecture. 

•  Development  of  unique  training  equipment. 

Deliverables:  Formal  deliverables  are  specified  in  DD  Form  1423. 
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•  Training  course  and  curriculum  outlines. 

*  Instruction  guides. 

•  Program  of  instruction  (POI). 

*  Audio  visual  aids. 

*  Classroom  training. 

•  Unique  training  devices. 

(For  the  formal  deliverables,  costs  associated  with  the  administrative  preparation,  review,  and 
distribution  are  excluded.  These  costs  are  included  in  the  appropriate  data  WBS  elements.) 


FIGURE  4-9.  iVaining  WBS 

4.4.4  Data.  The  data  element  (figure  4-10)  refers  to  all  deliverable  data  required  to  be  listed 
on  a  Contract  Data  Requirements  List,  DD  Form  1423.  The  data  requirements  will  be  selected 
from  the  DoD  Index  of  Specification  and  Standards  (DODISS)  and  Acquisition  Management 
Systems  and  Data  Requirements  Control  List  (AMSDL).  This  element  includes  only  such  effort 
that  can  be  reduced  or  will  not  be  incurred  if  the  data  item  is  eliminated.  If  the  data  are 
government  peculiar,  include  the  efforts  for  acquiring,  writing,  assembling,  reproducing, 
packaging  and  shipping.  Also  included  is  the  effort  to  transform,  reproduce  and  ship  data  identical 
to  that  used  by  the  contractor,  but  required  in  a  different  format  by  the  Government. 
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4.4,4.1  Software-related  data.  Software  data  refers  to  all  required  software-related 
documentaiion  listed  in  DD  Form  1423.  It  includes  all  data  requirements  in  accordance  with 
DOD-STD-2167A,  and  DOD-STD-1 467,  or  other  applicable  standards  tailored  for  the  particular 
program.  The  cost  data  collected  for  this  element  are  associated  only  with  the  preparation  and 
review  of  documentation  and  do  not  include  the  efforts  such  as  design,  requirements  analysis,  and 
coding  required  in  development  of  the  software.  Representative  activities  and  deliverables  are  as 
follows: 


Activities: 

•  Administrative  efforts  required  to  collect,  review,  prepare,  and  duplicate  deliverable 
data  in  the  format  specified  in  appropriate  Data  Item  Descriptions  (DlDs). 

•  Administrative  efforts  required  to  complete  and  provide  deliverable  data  to  the 
Government  in  accordance  with  pertinent  DIDs. 

Deliverables:  Formal  deliverables  arc  specified  In  DD  Form  1423.  Four  examples  of 
categories  of  data  are  shown  below. 

•  Technical  Publications:  The  technical  publication  element  refers  to  those  formal 
technical  orders  and  manuals  develop^  under  the  software  development  project. 

•  Engineering  Data:  The  engineering  data  element  refers  to  those  engineering  drawings, 
notes,  and  specifications  produced  during  the  project. 

•  Management  Data:  The  management  data  element  refers  to  those  data  items  necessary 
for  configuration  management  and  cost,  schedule,  and  project  management 
undertaken  during  the  project. 

•  Support  Data:  The  support  data  element  refers  to  those  data  items  designed  to 
document  the  logistics  support  planning. 
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4.4.4.2  Data  depository.  'Die  data  depository  element  is  defined  as  a  facility  designated  to  act 
as  custodian  in  establishing  and  maintaining  a  master  engineering  specification  and  drawing 
depository  service  for  government  approved  documents  that  are  the  property  of  the  U,.S. 
Government.  This  element  represents  a  distinct  entity  of  its  own  and  includes  all  effort  of 
drafting,  clerical,  filing,  etc.;  required  to  provide  the  service.  As  custodian  for  the  government, 
the  contractor  is  authorized  by  approved  change  orders  to  maintain  these  master  documents  at  the 
latest  approved  revision  level.  When  documentation  is  called  for  on  a  given  item  of  data  retained 
in  the  depository,  the  charges  (if  charged  as  direct)  will  be  to  the  appropriate  data  element.  All 
similar  effort  for  the  contractor’s  internal  specification  and  drawing  control  system,  in  support  of 
its  engineering  and  production  activities,  is  excluded.  The  software  data  library  Ls  a  repository  for 
all  software  design  records,  documentation,  source  code,  object  code,  and  executable  code 
associated  with  the  defense  system,  produced  and  maintained  during  development  (that  is,  the 
software  development  library)  and  throughout  sustainment.  Representative  activities  and 
deliverables  are  as  follows: 

Activities: 

•  Operation  and  maintenance  of  the  software  data  library  (including  the  software 
development  library). 

•  Construction,  modification,  or  expansion  of  the  software  data  library 
Deliverables:  Formal  deliverables  arc  specified  in  DD  Form  1423. 

•  Software  data  library  content  listing. 

•  Printed,  microfilm,  or  magnetic  media  copies  of  documents,  as  required. 

4.4.5  Peculiar  support  equipment.  The  peculiar  support  equipment  element  (figure  4-11)  is 
defined  to  include  the  design,  development,  and  production  of  those  deliverable  items  and 
associated  software  required  to  support  and  maintain  the  system  or  portions  of  the  system  while 
not  directly  engaged  in  the  performance  of  its  mission,  and  which  have  application  peculiar  to  a 
given  defense  materiel  item.  This  element  and  its  sub-elements  specifically  exclude  the  overall 
planning,  management  and  task  analysis  functions  inherent  in  the  work  breakdown  structure 
element  system  engineering/program  management,  and  common  support  equipment  presently  in 
the  DoD  inventory  or  commercially  common  within  the  industry  which  is  bought  by  the  using 
command  and  not  by  the  acquiring  command. 

4.4.5.1  Support  and  handling  equipment  The  peculiar  support  and  handling  equipment 
element  is  defined  as  the  deliverable  tools  and  handling  equipment  used  for  support  of  the  mission 
system,  including  the  software.  It  typically  includes  ground  support  equipment,  vehicular  support 
equipment,  powered  support  equipment,  non-powered  support  equipment,  munitions  material 
handling  equipment,  materiel  handling  equipment.  This  clement  includes  i.c.,  the  Life  Cycle 
Software  Support  Environment  (LCSSE)  required  to  maintain  the  mission  softv'are.  Included  as 
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an  inicgrai  part  of  the.  LCSSE  is  any  production  or  acquisition  of  duplicate  or  modified 
programming  support  environment,  test  and  emulation  equipment  delivered  to  the  procuring 
activity  for  use  in  maintaining  the  software. 


FIGURE  4-11,  Peculiar  support  t^quipment  WES 


Life  cycle  software  support  environment  refers  to  all  computer  hardware  and  support  software 
that  is  specifically  developed  or  purchased  commercially  to  aid  the  maintenance  of  the  prime 
mission  software.  Included  in  this  element,  e.g.,  are  compiler.,,  loader,  CASE  tcols,  licenses,  and 
other  computer  resources  and  utilities  that  are  determined  to  be  essential  to  support  the  software. 
If  these  items  are  acquired  to  develop  the  initial  software  and  later  the  .same  items  are  to  be 
provided  to  the  procuring  activity  for  post  deployment  software  support,  the  associated  cost  will 
be  included  in  the  cost  of  producing  the  PMP  and  subsystem  software.  The  structure  shown  in 
figure  4-2  should  be  used  when  it  is  desired  to  collect  lo  ver  level  information. 

4.4.5.2  Test  find  measuresnetst  equipment  This  element  is  defined  as  peculiar  or  unique 
testing  and  measurement  equipment  which  allows  an  operator  or  maintenance  function  to 
evaluate  operational  conditions  of  a  system  or  equipment  by  performing  specific  diagnostics, 
screening  or  quality  assurance  effort  at  an  organizational,  intermediate,  or  depot  level  of 
equipment  support.  It  includes  test  measurement  and  diagnostic  equipment,  precision  measuring 
CAtuipment,  automatic  test  equipment,  manual  test  equipment,  automatic  test  systems,  test 
program  se/s,  appropriate  interconnect  devices,  automated  load  modules,  tap(s)  and  related 
software,  firmware  and  support  hardware  (power  supply  equipment,  etc.)  used  at  all  levels  of 
maintenance  It  includes  packages  which  enable  line  or  shop  replaceable  unit,  printed  circuit 
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boards,  or  similar  items  to  be  diagnosed  using  automated  test  equipment.  The  structure  shown  in 
figure  4-2  should  be  used  when  it  is  desired  to  collect  lower  level  information. 

4.4.6  Operational/site  activation.  The  opcrational/site  activation  clement  (figure  4-12) 
refers  to  the  raal  estate,  construction,  conversion,  utilities,  and  equipment  to  provide  all  facilities 
required  to  house,  service,  and  launch  prime  mittsion  equipment  at  the  organizational  and 
iniermediale  level.  This  element  includes  conversion  of  site,  ship,  or  vehicle;  system  assembly, 
checkout,  and  installation  (of  mission  and  support  equipment)  into  site  facility  or  ship  to  achieve 
operational  status.  It  also  includes  contractor  support  in  relation  to  operaiional/site  activation. 
This  element  includes  efforts  associated  with  operational/siie  activation  of  software  maintenance 
and  enhana  mcnis  by  the  contractor  based  on  software  problem  change  reports  and  activities 
required  for  ihe  release  of  new  software  build/versions  as  depleted  if  figure  4-2. 


•/ 


FIGURE  4-12.  Operational  /site  activation  WBS 


4.4.6,1  Contractor  technical  support  The  contractor  technical  support  element  refers  to 
all  materials  and  services  provided  by  the  contractor  related  to  activation.  This  element  includes 
repair  of  rcpairablcs,  standby  services,  final  turnover,  etc.  This  also  includes  all  efforts  required  to 
ensure  that  implemented  and  fielded  software  continues  to  fully  support  the  operational  mission 
of  the  software.  This  support  begins  once  the  baseline  has  been  accepted  by  the  procuring  activity 
and  continues  until  the  responsibility  for  the  support  is  transitioned  to  the  Govcinment  software 
support  activity.  TTiis  clement  becomes  critically  important  and  its  use  more  widely  applied 
when  softwaic  is  developed  under  the  concept  of  evolutionary,  incremental  or  “build  a  little,  test  a 
little  and  field  a  little".  Additional  guidance  relating  to  software  support  concepts,  procedures, 
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«nd  activit'cs  is  dciailcd  in  MIL-HDBK-347.  When  software  is  being  developed  or  maintained,  it 
may  be  appropriate  to  collect  lower  Icve'  information  when  it  exists.  The  structure  shown  in 
figure  4‘2  and  definitions  should  be  used. 

4.4.6  2  System  assembUy,  instaUetion,  end  checkout  on  sste.  Ihe  system,  a.«.Gcmbly, 
installation,  and  checkout  on  site  element  refers  to  the  materials  and  services  involved  in  the 
assembly  of  mission  equipment  at  the  site.  This  cietneni  includes;  i.c.,  installation  of  mission  and 
support  equipment,  operations,  or  support  facilities;  and  complete  system  checkout  or  shakedown 
to  insure  achievement  of  cperaiional  status.  Where  appropriate,  specify  by  siie/ship  or  vehicle.  As 
shown  in  figure  4-J3,  this  element  refers  tc  the  software  product  logistics  support  activities  for 
the  release  of  ncv.'  software  versions  providing  enhancements  or  coirections  to  deficiencies. 
Support  activities  also  include  the  functions  related  to  procurement,  replication,  distribution,  and 
installation  of  technical  materiel,  to  .softv/are  media,  and  to  pen  onnel  support  required  for  the 
softwaie  version  release. 


FIGURE  4«  Systen?  assembly,  installation,  and  checkout  on  site  lower  levels 


4.4.6.2,1  Computer  prn'**'»tjn  media  preparation  &  checkout.  The  computer  program  media 
element  includes  all  activiiics  required  to  produce  the  delivery  packages,  e.g.,  fabrication  or  initial 
production,  .replication  or  reprogramtaing,  checknDut,  and  disti  ibution  of  the  approved  software 
version  in  ail  required  deliverable  ibrms  of  mag.netic  media,  paper  copy,  and  firmware  memory 
devices  that  were  dupiicaicd  or  modified.  This  clement  e.xciudes  the  initial  development  of  the 
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CPM.  The  iniiial  eiffovt  and  costs  arc  associated  with  the  integration  assembly,  test  and  checkout 
of  the  PMR  Representative  activities  include  the  foiiowingr 

•  Production  and  check-out  of  all  delivery  media  package  items. 

^  Delivery  ccxjKiination  and  distribution  database  maintenance, 

•  Coordination  with  hardware  component  modification  efforts. 

•  Preparation  of  media  installation  instructions  and  version  release  user’s  guide. 

4A.6.2,.2  Field  support.  Field  support  refers  to  the  activities  that  assist  field  personnel  (if 
necessary)  in  accomplishing  successful  program  loading,  updating,  and  operation  of  the  new 
software  version  for  the  associated  fielded  defense  system.  This  element  includes  activities 
associated  with  any  problems  and  resolutions  encountered,  or  training  to  the  user  community,  as  a 
result  of  the  software  change  release  package.  Representative  activities  include  the  following; 

•  Computer  program  media  installation. 

•  Providing  support  during  field  exercises. 

«  User  instruction  and  instructor  delta  training  for  new  functional  capabilities,  man- 
machine  interfaces,  and  computer-aided  instructior  software. 

•  Identifying  and  resolving  computer  program  media  data  release  package 
discrepancies. 

•  Resupply  of  computer  program  media. 

4.4.7  Industrial  facilities.  The  industrial  facilities  element  (figure  4-14)  refers  to  the 
construction,  conversion,  or  expansion  of  industrial  facilities  for  production,  inventory,  and 
contractor  depot  maintenance  (i.c.,  Post  Deployment  Software  Support  Activities)  required  by 
one  or  more  suppliers  for  the  specific  system.  This  element  includes;  i.c.,  equipment  acquisition, 
or  modernization,  where  applicable,  and  maintenance  of  the  above  facilities  or  equipment.  This 
element  also  includes  all  facility  resource  requirements  associated  with  the  software  support 
activity  (i.e.,  the  expansion  and  modernization  costs  associated  with  maintaining  the  software 
facility  and  system  lest  bed  and  with  operating  the  LCSSE.  This  element  excludes  the  acquisition 
cost  of  the  LCSSE. 
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HGURE  4-14.  Industrial  facilities  WBS 


4.4.5  Initial  spares  and  repair  parts.  Initial  spares  and  repair  parts  element  is  defined  as  the 
deliverable  spare  components,  assembly  and  subassemolies  used  for  initial  replacement  purposes 
in  the  materiel  system  equipment  end  item.  This  element  includes  the  repairable  spares  and  repair 
parts  required  as  initial  stockage  to  support  and  maintain  newly  fielded  systems  or  subsystems 
during  the  initial  phase  of  service,  including  pipeline  quantities,  at  all  levels  of  maintenance  and 
support.  This  element  excludes  development  test  spares  and  spares  provided  specifically  for  use 
during  installation,  assembly  and  checkout  on  site. 

4.5  WBS  relationship  to  program  and  risk  management  When  extending  the  WBS  with 
emphasis  on  software,  the  developer  is  not  precluded  from  decomposmg  software  beyond  the 
CSCl  element  identified  in  MIL-STD-881B  into  design  entities.  The  approach  presented  here  for 
software  is  consistent  with  the  DoD  Cost/Schedulc  Control  System  Criteria  (C/SCSC) 
requirements  and  with  the  Cost  Performance  Reports  and  the  Ccst/Schedule  Status  Report.  The 
C/SCSC  and  related  reports  use  the  work  breakdown  structure  as  deHned  in  the  contract  and 
extended  by  the  contractor.  A  cost  account  manager  is  typically  assigned  at  the  point  where  the 
contractor  organization  and  WBS  intersect.  The  cost  account  manager  generally  builds  work 
packages  and  typically  has  the  responsibility  of  managing,  monitoring  and  reporting  variances. 
The  lesuiling  combination  of  well  defined,  short  timespan  work  packages,  estimate  refinements, 
and  status  report  monitoring  provides  vital  management  visibility  into  a  program,  increasing  the 
chance  of  success.  A  correctly  developed  WBS  and  contractor  performance  measurement 
baseline  with  timely  reviews  reduces  risk. 
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Risk  management  can  be  further  enhanced  by  using  the  earned  value  performance 
management  concept.  Earned  value  is  an  objective  measure  of  how  much  work  has  been 
accomplished.  Without  earned  value,  one  can  only  compare  how  much  has  been  spent  with  what 
was  planned  to  be  spent,  with  no  objective  indication  of  how  much  of  the  planned  work  was 
actually  accomplished.  Comparison  between  earned  value  (i.c..  Budgeted  Cost  for  Work 
Performed  (BCWP))  and  planned  value  (i.e..  Budgeted  Cost  for  Work  Scheduled  (BCWS)) 
provides  an  indication  of  whether  or  not  schedule  is  being  maintained.  Comparison  of  earned 
value  and  actual  costs  (i.e..  Actual  Cost  of  Work  Performed  (ACWP))  provides  information  on 
whether  costs  are  overrunning  or  underrunning.  In  turn,  such  comparisons  allow  trend  analyses 
and  evaluation  of  estimated  costs  at  completion  for  all  levels  of  the  contract. 

Earned  value  measurement  requires  a  good  Performance  Measurement  Baseline  (PMB).  A 
PMB  is  a  time-phased  budget  plan  against  which  performance  is  measured.  The  key  to  a  good 
PMB  is  scheduling  work  in  a  way  that  is  compatible  with  risk  and  meaningful  in  terms  of  the 
program  milestones  and  technical  requirements. 

Since  software  is  primarily  a  labor  intensive,  people  oriented  activity,  cost  and  schedule 

- ,11..  -..I..*-  directly  to  manpower  loading.  Manpower  loading  deviations  from  the 

plan  are  typically  an  early  indicator  of  problems.  Estimate  updates  utilizing  the  information 
collected  and  associated  with  identified  characteristics  (suggested  guidance  is  given  in  Appendix 
B)  provide  a  way  of  forecasting  future  performance.  Thus,  comparing  the  performance  efficiency 
experienced  to  date  with  the  remaining  work  budgets  and  estimates  to  complete  provides  an 
independent  check  of  the  reasonableness  of  the  remaining  Budgeted  Cost  for  Work  Scheduled 
(BCWS)  and  the  projected  final  cost  of  the  project.  For  a  more  detailed  discussion  of  these 
concepts,  see  the  Cost  Schedule  Control  Systems  Criteria  Joint  Implementation  Guide. 

4.5.1  Contract  reporting  considerations.  Care  must  be  exercised  in  establishing  a 
reasonable  WBS  level  for  reporting  to  the  government.  Each  lower  level  increases  the  number  of 
reporting  elements,  with  a  commensurate  increase  in  reporting  burden  and  cost.  Except  for  high- 
cost  or  high-risk  elements  and  known  problem  areas,  the  level  selected  should  usually  be  no  lower 
than  Contract  Work  Breakdown  Structure  (CWBS)  CSCI  level.  Appropriate  reporting  elements 
below  the  CSCI  level  should  be  negotiated  for  each  contract.  While  this  handbook  establishes  a 
common  framework  for  defining  elements  below  the  CSCI,  it  is  not  to  be  interpreted  as  a  mandate 
to  require  routine  reporting  at  or  below  the  CSCI  level. 
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APPE?^IX  A 

PREPARATION  GUIDANCE  FOR 

WORK  BREAKDOWN  STRUCTURE  ELEMENTS  FOR  SOFTWARE 
10.  GENERAL. 

10.1  Scope.  The  purpose  of  this  appendix  is  to  identify  the  importance  of  collecting  software 
costs;  discuss  software  costs  reporting  objectives  and  cost  reporting;  and  provide  examples  of 
work  breakdown  structure  for  software  as  it  relates  to  defense  weapon  system  and  Automated 
Information  System  (AIS)  programs  and  contract  formulation.  The  information  contained  herein 
is  intended  for  guidance  in  compiling  software  cost  data  to  satisfy  applicable  standards  and 
acquisition  policy.  The  procedures  outlined  in  this  Appendix  are  what  is  typically  used  by  the 
DoD.  MIL-STD-881B  is  the  primary  source  for  developing  a  WBS.  The  overall  WBS 
acquisition  strategy  is  developed  relying  heavily  on  MIL-STD-881B,  specifically  section  11, 
user’s  guide. 

10.1  Collecting  software  cost  It  has  been  widely  recognized  that  a  majority  uf  coii  overruns 
encountered  on  systems  with  embedded  computers  are  associated  with  the  software.  Software 
development  time  and  cost  most  often  exceed  estimates  by  significant  amounts.  Lack  of  software- 
specific  guidelines  on  cost  tracking  by  the  Government  coupled  with  gross,  lump-sum  estimation 
of  the  software  development  cost  as  a  whole  by  the  contractor  and  bundling  of  software 
development  costs  into  total  system  development  costs  has  generated  risk  and  management 
problems  that  a  Work  Breakdown  Structure  for  Software  will  reduce.  When  software  is 
considered  to  be  a  major  category  of  cost,  the  contract  should  be  written  to  ensure  software  is 
managed  properly  and  that  adequate  software  cost  reporting  is  obtained.  In  view  of  software’s 
increasing  importance,  contractors  should  be  encouraged  to  adopt  state-of-the-practices  in 
software  development,  incorporating  those  practices  into  their  management  control  and  reporting 
systems. 

The  WBS  approach  permits  the  developer  and  maintaincr  to  focus  on  the  end  products. 
Implementing  proven  methods  of  statistical  process  control  at  the  measuring  points  identified  by 
the  WBS  will  permit  management  to  identify  insufficient  resources,  inefficient  segments  in  the 
process,  and  other  deficiencies  both  in  the  functional  areas  and  in  the  development  process. 
Implementing  adequate  management  control  systems  cost  and  schedule  and  cost  performance 
reporting,  can  enable  an  organization  to  influence  its  destiny  and  profits  by  managing  its 
performance  and  productivity. 
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20.  APPLICABLE  DOCUMENTS.  Guidance  regarding  cost/schcdule  coniroi  systems 
criteria  information  and  instructions  for  preparing  the  various  related  reports  are  detailed  in  the 
references  listed  in  section  2.1.2,  Other  Government  documents,  drawings,  and  publications. 

30.  PREPARATION  INSTRUCTIONS 

30.1  Pre  Request  for  Proposal  (RFP)  Release. 

30.1.1  Acquisition  plan.  During  the  preparation  of  the  acquisition  plan,  the  procuring  activity 
normally  will  identify  both  the  cost  reporting  items  that  will  be  required  in  each  contract  and  the 
contract  WBS  elements  to  be  reported  against.  Although  cost  reporting  data  requirements  are 
established  during  the  preparation  of  the  procurement  package,  it  is  prudent  practice  to  consider 
these  requirements  during  acquisition  planning.  Figure  A-1  provides  a  cost  reporting  chronology 
which  lists  activities  required  from  acquisition  planning  through  contract  award.  As  part  of  this 
effort  the  procuring  activity  will  prepare  a  Contractor  Cost  Data  Reporting  (CCDR)  plan.  This 
involves  assignment  of  cost  reporting  needs  and  selection  of  the  data  elements  that  will  be 
reported  against  in  the  particular  reports.  If  further  guidance  or  clarification  is  required,  the  Cost 
Analysis  Activity  can  assist  with  cost  report  selection  and  the  completion  of  the  CCDR  plan.  The 
iuiiwaiic  Suppul  I  /activity  is  prepared  to  assist  in  developing  the  WBS  including  the  software 
relatcd  elements. 

30.1.2  Data  call  and  solicitation  data  review  board.  During  this  next  phase,  the  procuring 
activity  must  coordinate  the  data  call  with  the  Software  Support  Activity  and  the  Cost  Analysis 
Activity.  The  Software  Support  Activity  can  provide  assistance  in  updating  the  WBS  and  the 
associated  software  elements,  described  in  Section  4,  which  should  be  inch:dcd  in  the  Statement 
of  Work  (SOW).  The  Cost  Analysis  Activity  has  sample  Contract  Data  Requiremicnts  Lists 
(CDRLs),  DD  Form  1423,  and  Statements  of  Work  (SOWs)  available.  The  Cost  Analysis  Activity 
can  also  provide  assistance  in  developing  contract  peculiar  clauses. 

30. U  Identify  software  WBS  elements.  ITic  next  step  is  to  identify  those  sub-systems  in 
which  software  will  be  a  critical  or  high  risk  item.  Software  is  identified  i.n  two  ways  for  the 
development  of  a  work  breakdown  structure:  (1)  that  which  is  part  of  the  defense  system/sub¬ 
system  it  supports,  and  (2)  that  which  is  stand  alone  (defense  materiel  items  which  have  fully 
automated  capabilities)  and  may  support  its  own  program  or  contract  work  breakdown  structure. 
Figures  A-2,  A-3  and  A-4  provide  examples  of  how  software  should  be  addressed  as  part  of  the 
defense  system/sub-system  and  as  a  stand  alone  pure  software  devciopment/upgrade  effort.  The 
WBS  for  stand  alone  software  system  refers  to  the  aggregation  of  software  and  appropriate 
common  WBS  elements  required  to  develop  and  to  produce  a  software  capability  for  a  command 
and  control  system,  radar,  slock  point  sy.siem  and  information  system,  etc. 
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30.1.4  SaiTipie  work  breakdown  stnictare. 

30.i.4..1  Weapon  system.  For  this  example,  the  Navigation  Guidance  element  is  broken  out  as  a 
separate  item  in  accordance  with  appendix  B  (Elcctronics/Aulomaied  Software  Sy.stem)  of  MIL- 
STD-881B  and  augmented  with  software  WBS  eiements  discussed  in  this  handbook,  refer  to 
Figure  A-2. 

30.1.4.2  Automated  information  system  (AIS).  For  this  example,  a  Command  and  Control  AIS 
system  is  chosvtn,  refer  to  Figure  A-3.  The  Command  and  Control  Automated  Information 
System  is  broken  out  in  accordance  with  Appendix  B  (Elcrtronics/Automated  Software  System) 
of  MIL-STD*881B  and  augmented  with  software  WBS  elements  discussed  in  this  handbook. 

30.1.4.3  Stand  alone  software  system.  For  this  example,  refer  to  Figure  A-4,  a  supply  system 
utilized  by  supply  centers  and  depots  is  chosen.  Since  hardware  was  not  part  of  the  acquisition, 
the  software  system  is  the  Primary  Mission  Product.  This  handbook  will  be  used  for  acquisitions 
where  the  PMP  is  the  software  or  software  system  and  no  hardware  is  included  in  the  acquisition. 

30.1.5  Correlate  WBS  to  draft  statement  of  work  (SOW)  and  draft  contract.  The  WBS 
development  should  be  developed  hand-in-hand  with  the  draft  SOW  and  the  draft  contract.  A 
matrix  should  be  developed  which  shows  relationships  between  the  WBS,  the  SOW,  and  the 
contract  line  item  number  (CLIN)  structure.  Another  important  part  of  the  draft  RFP  which  is 
related  to  the  WBS  is  Instructions  to  Offeror.  Within  these  instructions,  the  program  office  should 
explain  which  WBS  items  are  mandatory,  which  items  need  to  be  extended,  and  what  minimum 
level  of  break-out  is  requirexl.  The  instructions  should  also  include  the  requirement  for  the  offeror 
to  provide  a  matrix  as  described  above. 

An  example  of  wording  to  include  in  the  Instructions  for  Offeror  is: 

“Costs  shall  be  broken  out  by  WBS  elements  lAW  the  attached  WBS.  Offeror  shall  extend  the  WBS 
to  the  lowest  level  necessary  to  justify  cost  estimates.  Offeror  shall  provide  a  matrix  which 
correlates  WBS  elements  with  SOW  tasks  and  the  CLIN  strucuire.  These  instructions  apply  only 
for  proposal  preparation  and  submission,  they  do  not  establish  cost  reporting  requirements  for 
post  contract  award  efforts. " 

30.1.6  Tie  the  WBS  to  the  cost/schedule  reporting  requiiYments.  Work  with  the  contracting 
officer,  data  manager  and  local  cost  analysis  activity  to  ensure  that  the  appropriate  contraci 
clauses  and  data  items  are  tailored  to  reflect  your  information  needs.  Reference  Contractor  Cost 
Data  Reporting  pamphlet  (AFLCP  SOO-I.'j,  AFvSCP  800-1.5,  AMC-P  715-8,  NAVMAT  F-5241) 
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FIGURE  A-3.  Sample  program  WBS  for  Automated  Information  System 


LEVEL  1 
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for  specific  guidance.  Remember  you  should  be  requiring  only  the  minimum  amount  of  re  porting 
necessary  to  achieve  effective  management  control.  Per  MIL-STD'881  B,  “...  routine  .^porting  ts 
at  level  3  of  the  contract  WBS  or  higher,  e.xcept  for  high-cost,  high-risk,  or  other  high-interest 
elements  that  are  at  lower  levels.”  If  a  particular  software  itcin  is  not  high-cost,  high-risk,  or  high- 
interest,  level  3  reporting  should  suffice.  On  the  other  hand,  if  the  software  item  falls  into  one  cf 
the  “high"  categories,  the  program  office  must  decide  how  low  a  level  of  reporting  is  necessary. 
Appendix  B  is  a  suggested  approach  which  can  provide  the  necessary  parametric  data  and 
characteristics  or  attributes  to  perform  cost  estimates.  These  estimates  can  then  be  related  <o  the 
WBS.SW  to  provide  management  insight  into  the  SW  development  effort.  In  turn,  actual 
information  collectexi  at  the  WBS.SW  elements  can  be  used  to  calibrate  estimates  for  future 
efforts. 

30.1.7  Send  out  a  draft  solicitation.  After  completing  the  above  steps,  and  if  time  permits,  send 
out  a  draft  RFP  for  comments.  This  will  provide  the  program  office  with  feedback  from  industry 
regarding  the  WBS  and  reporting  requirements. 

30.2  Final  solicitation  preparation.  Incorporate  appropriate  feedback  from  the  draft 
solicitation,  conduct  appropriate  coordination  and  reviews  and  distribute  the  final  solicitation. 

30.3  Proposal  acceptance  and  source  selection.  In  response  to  the  program  WBS,  which 
includes  the  WBS.SW,  contained  in  the  Government  solicitation,  the  contractor  provides  the 
contract  WB,S.  The  contract  WBS  identifies  the  framework  for  reporting  program  cost,  schedule, 
anu  technical  performance.  The  contractor  will  use  this  proposed  Vv  BS,  including  the  WBS.SW, 
and  expand  it  to  lower  levels.  This  provides  Government  software  managers  with  a  basis  for 
uniform  planning  and  reporting  statu.s.  This  also  provides  input  which  will  be  used  for  preparing 
the  Cost  Performance  Report  (CPR)  and/or  the  Cost/Schedule  Status  Report  (C/SSR). 

30.4  Contract  award.  During  contract  negotiations,  the  WBS  r.:ay  be  changed  from  the  initial 
input.  The  final  WBS  is  negotiated  and  incorporated  into  the  contract.  On  completion  of  contract 
negotiation,  the  CCDR  plan  becomes  the  defining  document  for  the  e.<chdijge  of  cost  data 
information.  Refer  lo  DODI.  5000.2  for  specific  guidance  for  pieparing  the  CCDR  plan. 
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30.5  Software  element  identifier.  During  reporting,  to  facilitate  the  roll-up  of  software  cost 
data,  an  identifier  for  software  related  items  is  recommended.  For  example,  the  letter  “SW”  can 
be  used  as  an  extension  to  the  reporting  element  number,  as  shown  in  Figure  A-5.  This  is  further 
expicined  in  MIL-STD-881B,  User’s  Guide  Section  II,  paragraph  5.6. 


FIGURE  A«S.  Software  element  identifier 


49 


Technical  Report  Describing  Contents  of 
MTL-HDJlK-ni  praD) 


/iPPENDlX» 


SOFTWARE  CHARACTERISTICS  DATA  COLLECTION 


10.  GENERAL. 

10.1  Scope.  This  appendix  provides  suggested  gnidamc  for  coUeciing  dat?.  on  projeci 
charecteristics  related  to  project  size,  conplcxiiy,  functions,  schedule  and  level  of  effort.  So.ftwarv: 
characteristics  identified  in  this  appendix  are  an  fcppiopriaio  set  of  fccuced  data  items  that 
characterize  the  software  being  developed,  'k'hesc  characteristics  provide  valuable  data,  which 
when  collected  and  analyzed  by  tiie  program  manager  (both  government  and  industry),  teinforces 
rntnagement  indiceiors  with  credible  software  resource  consumpiio.n  citimates.  The  information 
contained  herein  is  intended  for  guidance  only. 

10.2  Information.  This  appendix  provides  a  suggested  project  questionnaire  which  may  tc  used 
for  collecting  the  project  characteristics  data.  This  infoimatior*  is  important  for  providing  projec* 
related  data  necessary  to  improve  software  acquisition  planning,  cost  estimating,  and  cost 
estimating  model  calibration.  The  questionnaire,  Software  Parametric  Data  Collection  Form. 
follov/s  the  appendix.  This  form  is  intended  to  be  tailored.  All  information  shoula  NOT  be 
required  of  all  projects  at  all  times.  The  software  characteristics  identified  suppc  ii  input  lo  most 
cost  and  schedule  estimation  tools. 

20.  APPLIC/iELE  DOCUMENTS.  This  section  is  not  applicable  to  this  appendix. 

30.  Projecl/Computer  Software  ConDguration  Item  (CSCI)  Questionnaire  Report.  The 
Project/CSC'  Oueslionnaire  Report  is  contained  on  the  following  pages  The  questions  asked 
addre*:s  both  project  specific  data  and  CSCIfs)  specific  d^ta. 

30.1  Data  maturity.  As  the  ptoject  matures  (he  software  characteristic  data  collected/submittcd 
are  increasingly  credible.  Estimated  respon.'tes  should  be  indicated  with  an  asterisk  on  the 
questkmnairc. 

4C.  Who  needs  the  Data.  TTie  software  characteristics  data  collected  provides  information 
required  by  cosi/pcrformance  analysts,  project  software  personnel,  and  projeci  management 
personnel.  The  data  caii  be  used  to  continuously  monitor  and  manage  software  development  cost 
£ad  schedule. 

50.  When  to  collect  the  data.  'Fhc  frequency  at  which  the  infoimation  is  to  be  collected  should  be 
determined  by  the  procuring  activity  based  or,  a.mong  others,  the  following  criteria: 


a.  Risk  (technical  and  mnnagemeni) 


Ttdmical  Report  Peacribing  Cof)t<>c.to  of 
MIL-HDBK.ni  (Dk«P) 


b.  SchcduJc  corstraini 

c.  Ct^i  constraint 

d.  Anticipated  recjuitemcntj  volatility 

50.1  MinSinium  repi>rtlng  frequency.  IHie  data  or  sub-set  may  be  collected  during  any  point  of  the 
contract  period  of  performance.  However,  it  ic  lagge-J'.cd  that  at  a  minimum  this  data  be  collected; 

d.  To  back  jp  cost  propejals  irr  soitwarc  costs. 

b.  A.t  major  software  mciestoiic  rev  iews  such  ns  Prclimina.7  Design  Review 
(FDR),  Critical  Desijm  Rf vjfv/  (CDR)...eic.,  to  be  utilized  by  the  pro.’^uring  activity  to 
update  estimates  of  cost  and  sciiedule. 

c.  At  the.  i.nd  of  ‘he  contract  hs  historical  Uua.  The  software  characteristics  data 

wil!  be  used  to  improve,  future  soflwar»3  acquisition  planning,  cost  estimating,  and  cost 
model  calibration. 

50.2  Statement  of  Wcik  (SOW)  input.  The  oata  to  be  collected  can  be  specified  as  a  deliverable 
(DD  Form  J  423)  in  the  contents  of  the  SOW.  it  is  suggested  that  DI-MISC-80048  Scientific  & 
fcchnicai  Report  Summary  be  used  lO  provide  this  information 


7'echfkicai  Kejport  D^scrf^ing  Cbn<*ntf  Of 
NriL.KDBK.i7i  (DmlftJ 


THIS  PAGE  IS  INTENTIONAIXY  1-EFT  BLANK 


PROJECT /CSCI  QUESTIONNAIRE  REPORT 


Complete  this  form  to  the  hisst  of  your  ability  for  the  project  in  question.  If  the  question  is 
not  apjf^l’cabie,  please  mark  it  N/A.  If  you  don't  know  the  answer,  leave  it  blank. 

1.  Firm  or  organisation:  _ _ 


2.  Contract  number; 

3.  Customer  name; 

4.  Project  overview  description;  (Should  describe  the  CSCI  being  developed) 
To  include:  Functionality  -  expected  impact  of  integrating  COTS. 

CSCI  *  Computer  Software  Configuration  Item 
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A  -  PROJECT  DESCRIPTION 


1 .  Applications  domain 

[  ]  Auiomation 
[  ]  Command  &  Ccnirol 
( ]  Signal  proocinng 
[  ]  Trainers 
[  ]  Interface  systems 
[  ]  Data  processing 
[  ]  Production  control 
[  ]  Prooeu  control 
[  ]  Rotastics/Mechanical 
{ ]  Manned  Flight 

2.  Complexity 

a.  Rate  The  DifGculty  Of  Processing  Logic 

[  ]  Simple  processing  logic,  straight-forward  I/O 
[  ]  Routine  nesting,  minimal  interface  with  Operating 
systems,  standard  I/O 

b.  Mathematical  Complexity 

[  ]  Simple  algorithms  and  simple  calculations 
i  j  Algor,  ihms  and  calculations  of  average  complexity 
( ]  Many  difficult  algorithms  and  complex  calculations 

c.  List  the  percent  of  total  soutxx  code  allocated  to  each 

Real-Time  _ _ % 

Time-Constrained  % 

d.  Database  Complexity 

( ]  Simple  data,  few  variables,  low  complexity 
( }  Multiple  files,  fields  and  data  interactions 
[  ]  Highly  complex 

3.  Reliability 

a.  Most  serious  effect  of  a  software  failure 
[  j  inconvenience 
( ]  Loss  of  human  life 
[  I  Major  flnandal  loas 


{ ]  Business 
( ]  Communications 
( ]  Teal  systems 
[  ]  Avionics 

( ]  Graphic,  image  processing 
{ ]  Environmenta/Toolt 
t  ]  Support  software 
i  ]  Sdentiflc 
[  ]  Unmanned  flight 
[  J  Other _ 


[  ]  Difflcull  highly  nested  logic,  real-time  processing 
( ]  Complex  dynamic  resource  allocation,  multipie 
exception  handlers,  recursion 

[  ]  Majority  of  simple  algorithms  and  calculations 
( ]  Some  difficult  or  complex  calculations 
( ]  Not  Applicable 

I  of  the  following  operational  timing  requirements: 
On-line  _____  * 

Non-Time-Critical  _ _ % 

[  ]  Simple,  numerous  variables 
[  ]  Compies  file  structure 


( ]  Easily-  recoverable  lo 
{ ]  Moderate  lost 


b.  Backup/Rscovery  considerations 

[  ]  Data  protection  beyond  regular  backup  required  [  ]  No  special  backup  requiremenu 

( ]  Alternative  methods  need  to  be  developed  in  cue  of  software  failure 

4.  Is  this  the  first  system  of  its  kind  for  your  organization  ? 

IJYea  [JNo 
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5.  Security  Lsvel 

What  are  the  security  requirements  on  the  development  end  on  t  he  target  computing  environments? 


OClastO 

rjB2 

(ICl 

IJB3 

l]C2 

( ]  Gass  A1 

llBl 

( J  Other 

[  ]  None 

6.  Reused  Code 

a.  Logical  Complexity  of  Reused  Code: 

( ]  Simple  algorithms  and  simple  caloulations 
[  j  Algorithms  and  calculations  of  average  oomplexity 
( ]  Many  difTiculi  algorithms  snd  complex  calculations 

b.  Structural  Complexity  of  Reused  Code: 

[  ]  Noitprocedund  (gersersted,  query,  spreadsheets,  etc.)  [  ]  Well  structured  with  retvable  modules 

[  ]  Well  structured  (small  modules  atxi  simple  paths)  [  ]  Fair  structure  but  some  complex  paths  and  modules 

{ ]  Poor  structure  with  msny  oocTiplex  paths  and  modules 

c.  Database  Complexity 

I  ]  Simple  date  with  few  variables  and  Jittle  oomplexity 

I I  files,  fields,  and  data  interactions 
{ ]  Very  ctvnplex  date  elements  and  data  interactions 

d.  Select  the  intended  use  of  the  majority  of  the  software  packaged  for  reuse: 

( ]  None  [  ]  Reuse  within  single  mission  products 

( ]  Reuse  actoss  tingle  product  line  { )  Reuse  in  any  application 


( ]  Several  data  elements  but  simple  data  rtlsiionshipii 
( ]  Ccanplex  data  elements  snd  complex  data  interactions 


( ]  Majority  of  simple  algorithms  and  calculatioits 
[  ]  Seme  difficult  or  complex  calculations 
{ ]  No  reuse 


J 
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B  -  DEVELOPMEW  METHODOLOGY 

1.  ViUesioncs 

Enter  the  expected  and  actual  dates  for  ^ch  milestone  below  or  M/A  If  the  milestone  does  not  apply  to  this 
project.  If  an  expected  date  is  an  estimated  date  rather  than  a  contract  date,  put  an  asterisk  after  that  dete. 
Provide  this  data  for  each  incremental  development. 


Milestone 

Project  Start  Date 

System  Requirements  Review  (SRd) 

System  Design  Review  (SDR) 

Software  Specification  Review  (SSR) 

System  Hardware  Preliminary  Design  ReviewfPDR) 
System  Software  Preliminary  Design  ReviewfPDR) 
S)rstem  Hardware  Crilica’  Design  Revidw  (CDK) 
System  Software  (Critical  Design  Review  (CDR) 

Test  Readineaa  Review  (TRR) 

Functional  Configuration  Audit  (FCA) 

Physical  Configuration  Audit  (PCA) 

Formal  Oualillcation  Review  (FOR) 

Operational  Teat  and  Evaluation  (GTE) 

Project  Completion  Date 


Expected  Achial 

Dale  Date 


Schedule 

a.  Select  the  schedule  and  staffing  corstraints  that  best  describe  this  development: 

[  ]  Normal  average  schedule,  effort,  and  quality  |’  ]  Shortest  development  schedule,  extra  staffing 

[  ]  Ixrwest  oosi  with  reduced  staffing  |  ]  Highest  quality  a.id  reltability 

[  ]  Shortest  schedule  with  high  quality  and  reliability  [  ]  Match  staff  size;  '.riiit  normal  development 

[  I  Match  slnff  size;  with  shortest  schedule  [  ]  Maitth  staff  size;  vritn  very  high  quality 


Development  paradigm  employed  (check  all  thtt  apply); 
[  ]  Waterfall  development 
[  ]  Phased  builds 
( j  Rapid  protoiypirg 

I  ]  Other _ _ 


[  ]  Increments:  development 
{ }  Spiral  development 
( ]  Pilot  development 


Software  Rrviews 

a.  Select  all  informal  reviews  held  on  the  software  during  this  development: 

[  ]  Design  walkthroughs  [  |  Design  inspections 

i  ]  Code  walkthroughs  ( ]  Code  inapretions 

I  ]  Other _ _ 
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5.  System/Softwarc  RequiremcrtJs 

a.  Select  the  option  that  corretpoDds  to  the  level  of  dcOniiion  and  understanding  of  syttem  requirements: 


[  ]  Veiy  Itnte  definition  end  undenUiiiKlifig  of  eyetem 
requirements 

I }  Fairly  complete  definition  and  undeiatanding  of 
system  requirements 

c.  Rate  requirements  volatility  during  development: 

[  ]  No  changes 

[  ]  Frequent  non-critical  changes 
f  J  Frequent  moderate  changes 

6.  Design 

a.  Rate  die  maturity  of  the  design  concepts  used: 

{ }  Experimental 
( ]  State-of-lhe-ari 


[  ]  Questionable  definitioii  and  understanding  of  system 
requirements 

[  ]  Very  complete  definition  and  undemanding  of  system 
requiiemems 

[  j  Small  non-critical  changes 
{[  ]  OocasionQi  moderate  changes 
( )  Miny  large  changes 


{ ]  Evolutionary 
I  ]  Mature 


b.  Select  ssny  of  the  following  design  technologies,  siraicgies,  and  tools  {used: 


[  ]  Applications  Generator 

( )  case  tools 

( ]  Relational  database 

( J  4GL  or  SGL 

( j  Exception  handiing 

{ ]  Management  toolset 

[  ]  Database  management  system 

[  ]  Continuous  integration  via  padcagt  speciricaiiotut 

[  ]  Other _ _ 


(  j  Objea-oriensed  metliods 
[  ]  Structured  analysis 
( )  Query  Language  (SQL) 

[  ]  Reuse  libraries 

[  ]  Front  loaded  scheduling 

{ ]  Cost  and  schedule  models 

{ ]  Small  up-froni  design  teams 

[  ]  Ada  Fcogram  Design  Language  (PDL; 


7.  Integration 

Rate  the  expected  level  of  d.Jficulty  of  integrating  and  testing  the  CSCIs  lo  the  system  level: 

( }  Very  little  integration,  no  complex  interfaces  { ]  Average  degree  of  complexity  system  integration  and 

( ]  Several  system  interfaces  with  some  txjmplex  inierfat:«s  interface 
( ]  Complex,  time-intensive  system  integration  process  anticipated 
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C-SOrrWARESIZE 

1,  Size  Estimates  (indicate  if  based  on  liistorica!  data  or  esiiinatc,  and  wse  tmmbcr  if  estimate) 

a.  Number  of  software  CSCI  in  this  system; _ 


Select  the  basis  for  size  estimates; 

[  ]  intcusand  of  Source  Lines  of  Code  (KSLOCs) 
{ ]  Fimetion  Points 
1 1  _ 


( ]  Carriage  telums 
( )  Sunisoluns 

1  i  Sot^vam  Eng'.noMng  Institute  Method 


c.  Enter  the  rsquested  sizing  infonruttior.  below,  in  thousands  of  uitits 

CSCI  New  Size  Reused  Modified  Lsagimge 


>%«4W  4«4S<\  ^W4 

Source  Code  Type 

Operating  Systems.. . 

Interactive  Operarjons . 

Real-Time  Command  &  Control. 

On-line  Ctommunicatioas . 

D.sia  Storage  &  Retrieval . 

String  Manipu.ation . 

Mathematical  Operationa . . 

Other . 


%Co<je 


%  New  Design  %  New  Code 


3.  If  the  system  was  sized  using  function  points,  protride  the  following  unadjusted  function  point  information; 
».  Number  of  inputs  (unique  major  data  types  that  enter  the  system):  _____ 

b.  Number  of  ouQtuts  (unique  logical  major  report  formats  the  system  will  generate): _ _ 

c.  Number  of  inquiries  (types  of  queries  that  result  in  informatioi’aJ  searehes  and  responses):  _ _ 

d.  Number  of  extemai  interfaces:  _______ 

e.  Number  of  inemal  files  (unique  logical  files/daiabases  used  by  the  application); _ 

4.  Database  size  (amount  of  code  devoted  to  database  definition  accounts  pluse  databasse  size  in  memory) 

Database  size,  as  a  percenuige  of  total  program  size: _ %  (source  lines  of  code) 
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D  -  PROJECT  STAFFING 


1,  Staff  Size 

i.  Minimum  tMityaIze‘ 

b.  Maximum  sMff  size: 

2.  Staff  SitiK/ExperiPncf 

a  Avurage  Anaiyats*  expetiance  with  similar  qjplictiUoRs: _ _  years  months 

b.  Average  Programmers’  experience  with  this  host  machine;  y^rs  ______  _  months 

c.  Average  Analysts'  experience  with  chosen  development  Methodology : _ _  ^ears  months 

( ]  Completely  new  development  methodology  [  ]  Minor  experience  wiih  development  mvthodology 

f  ]  Extensive  experioxir.  with  dnvelopmen;  methodology 

d.  Average  Aralysts’  experience  with  (he  Dcvelopmeni  language:  ________  y«ars _ _  months 

( ]  Compielely  new  development  language  ( ]  EdunationaJ  or  training  in  language 

[  ]  Some  experiencK  with  devdopmen;  language  { ]  Extensive  experience  with  developmecil  language 

e.  Progremmers’  Atarage  Ada  Environment  Experience:  ______  years  _ _ months 

f.  Development  organization’s  experience  developing  this  type  of  application 
( ]  This  eppliostioit  is  a  new  prp|cct  not  in  our  current  line  of  buaineta 

[  ]  This  eppliottlon  is  a  normal  development  prpjeci  that  in  pan  of  our  current  line  of  businere 
( j  I'his  opplicahon  is  a  familiar  type  of  project  having  alivady  been  deveioped  by  the  company  before  or 
aimilar  to  other  projecta  we  have  developed 

[  ]  Many  applications  of  this  ty^  he^'c  baen  developed  by  the  company  (greater  than  7} 
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E .  COMPUTER  SYSTEM 


1.  Development  Environment 

a.  Rat?  the  virtual  machine  volatility  of  the  development  system  based  on  frequency  of  major/minor  changes: 

[  ]  12  months  (majoryi  month  (minor)  { ]  6  months/2  weeks 

[ }  2  montWl  wv:«k  { ]  2  we«ks/2  days 

b.  Select  the  following  option  that  best  assesses  the  embedded  features  of  the  de  veiopmcnt  systems: 

I  ]  Hardware  is  to  be  developed,  but  its  oompletion  will  occur  long  before  the  software  is  to  be  ready 

[  j  Hardware  is  to  be  developed  on  Itie  contract,  it  ia  to  be  develo'  ed  concutrently  with  the  software  ana 
the  hardware  can/does  have  major  impacts  on  the  software 
( ]  Hardware  is  to  developed  on  the  contract,  it  is  to  be  developed  ecncurrently  with  the  software  bu'  the 
hardware  has  little  impact  on  the  software 

[  ]  No  new  hardware  is  to  be  developed  undi^t  the  effort;  there  will  be  no  impact  on  the  software 
development 

2.  Target  Computer  Configuration  (complete  this  section  only  if  the  development  sysi/jin  differs  from 
the  target 

a.  Rate  th;  virtual  tiuichine  volatiljft/  of  the  target  system,  based  on  number  of  major/minor  changes: 

[  j  i2  mcnihs  (major)/!  month  (minor)  ( ]  6  monthz/2  weeks 

f  J  2  months/'i  week  ( j  2  weekit2  ctsys 

b.  Identify  the  system  architecnire; 

[  j  Centralized  (single  processor) 

[  ]  Loosely-coupled  (multiple  processor) 

[  ]  Distributed  (centralized  database) 

3.  Performance  Requirements 

a.  Main  Storage  Constraint.  Main  storage  refeis  to  direct  random  access  storage  such  as  core, 

integrated-circuit,  or  plated-wire  storage;  it  excludes  such  devices  as  drums,  disks,  tapes.or  bubble 
storage.  Indicate  the  percentage  that  best  reflects  the  main  storage  expected  to  be  used  by  any 
sub-systems  consuming  the  main  storage  resources.  _ _  ’  % 

b.  Overall  Target  Hardware  Constraints.  Overall  hardware  refers  to  processor  memory,  speed,  and  throughput 
[  ]  Qoae  to  100%  utilization 

[  ]  Difncull  hardware  capacity  limilationa  (73%  to  90%) 

( ]  Average  hardware  capacity  limilationa  (60%  to  73%) 

[  ]  No  hardware  capaaty  limiutiona  (iesi  than  60%) 


f  J  Tightly-coupled  (multiple  processor) 

[  ]  Functional  processons  communication  via  a  bus 
[ }  Distributed  (distributed  database) 
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F  -  DEVELOPMENT  ENVIRONMENT 


Project  Organization 

a.  Check  all  of  the  company  organizatioac  included  in  effort  estimations/actuals 


[  ]  Sy&teiniu  engineering 
( ]  Marketing 
[  ]  Program  management 
[  ]  Configurstion  management 
( ]  Data  management 
[  ]  Dalaboac  administration 

b.  Organizational  Interface  Complexity 

[  ]  Single  customer,  single  interface 

[  ]  Multiple  internal  and  external  interfaces 
( ]  Multiple  internal  interface  single  external  interface 

c.  Multiple  site  development 

( ]  Single  site  and  single  organization 
[ )  Multiple  sites,  same  general  location 


[  ]  Uaer  department 
( ]  Software  development 
[  ]  Software  test 
{ ]  Quality  asaurance 
{ ]  Indepe.ideni  V&V 
[ )  Other _ _ 


[  ]  Single  customer  oo-located  with  developer 
[  ]  Multiple  inlerfacea  geographically  distributed 


[  ]  Single  site  and  multiple  organizations 
I  ]  Multiple  sites,  located  SO  miles  or  more  apart 


xvcdOUrCCS 

Select  the  percentage  of  time  that  the  development  computer  is  available  for  use  on  this  project: 

[  ]  10%  [ )  40% 

[  ]  70%  ( )  100%  (fully  dedicated) 
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